Super FR: Improvements for the Backlinks (and Search) pane

[JamesKF]

MOD EDIT: Renamed, Edited, Updated some links.

This topic is to consolidate several feature requests concerning the backlinks pane. It has already improved a lot, but I think it lacks 4 fundamental features, that would make it perfect.

1. More/Hierarchical context

Use case or problem

When using the following daily note :

Backlinks pane of project A does not show parent item thus lacks of visibility. We would need the following changes :

Proposed solution

Show more context option is great, but it should be more customizable, mainly with the option to directly show a parent item (possibly without in-between items leading to the parent item).

Current workaround

On each search result, click on the upper arrow ^ to show more context (but it doesn’t immediately show parent item if there are intermediate items in-between !).

Related feature requests

Backlinks and Search - Display Information based on hierarchical document structure (bullet list level or enclosing header breadcrumbs)

When a wikilink is present in a line item of a bullet list, the corresponding entry in the backlinks pane is just that line item, If “show more context” is active, the children are shown. [image] It would be nice to provide more/better context for that line item. In particular, outliner-based products show the parent item too.

---

2. Filter with block granularity

Use case or problem

Using the same daily note as above, search results in the backlinks pane are not filterable by blocks. In the example below, I wanted to get blocks with both [[ProjectA]] and #idea. Unfortunately, it returns any block containing [[ProjectA]], as long as there is a #idea anywhere in the same page ! This is because search/filter is made at page level, not block level.

See a more detailed example here and here.

Proposed solution

Possibility to filter backlinks on a block level. This would unlock the possibility to use inline tags in Obsidian. Obsidian already shows each block where the backlink appears : it seems so close to being able to filter each block, and it would be a game changer !

Current workaround

Change your workflow or use Logseq in parallel with Obsidian.

Related feature requests

Filter results in the Backlink pane with block level granularity

Currently, the filter works at page level (even block-level operators). Simply put, the results returned by the filter are used to select the pages and the backlink locations are shown. This post is to summarize some internal discussions about improving the behavior of the backlink pane filtering system (same thing goes for the backlink in document). Two ideas for improving: (Base) Introduce a button for “match anywhere on the linked notes”. The filter turns into simple, plain-text, block-…

Using Daily Notes as a convert from Roam

This post discusses the idiomatic workflow translation from Roam to Obsidian. For official instructions on export/import, see the official Roam Research import guide For the past few weeks and over the next month or so, I’m attempting to transition my work from Roam to Obsidian (mainly due to slow performance when I push it with queries/backlinks). I’ve been using Obsidian for a while and loving it to manage the markdown files on my Jekyll based website, but I’m trying to see if I can really wo…

---

3. Direct edit

Use case or problem

Backlinks pane items are not editable like a fully fledged note. Impossible to quickly copy/paste all information in the backlinks pane to share it elsewhere. Need to go into each element if you want to edit or copy something.

Proposed solution

Direct edit capabilities for all items in the backlinks pane. Possibility to copy all the backlinks pane items in a single shot.

Current workaround

Open each item separately to edit it.

Related feature requests

Edit transcluded (embedded) notes (blocks) in place (likely requires WYSWYG first)

Allow editing a transluded document or block in place (without opening the original file) Most likely a good implementation depends on A WYSIWYM (Typora-like) editing mode

4. Save backlinks pane state/preferences per note

Use case or problem

State of backlinks pane (collapse or not, show more context or not, sort, filter) is not saved per note.

Some notes require a backlinks pane fully collapsed with a given filter, others require a fully expended backlinks pane, with more context shown.

Proposed solution

Possibility to save the state of the backlinks pane individually, per note.

Workaround

Set the backlinks pane again, each time you reopen the note.

Related feature requests

Retain/remember status of “Backlinks in document”

Use case or problem I use backlinks extensively to find notes related to a particular concept, and have a keyboard shortcut to enable/disable backlinks in the document. This works great, except that backlinks regularly disappear and I have to re-enable them…and when I do, they are expanded automatically which makes it much harder to see which notes contain a link to the current note. Of course, I then have to use the mouse to click on the collapse icon so I can see just the linking notes and …

Request: toggle backlinks in document per note

Use case or problem For some notes I always want to see backlinks. For other notes, they are irrelevant. Especially on mobile, having to swipe for backlinks is a pain (pun!). If I could “toggle backlinks in document” per note, then I could set it per note and forget it. Current workaround Dataview

Thank you for reading this feature request, and please don’t hesitate to share your thoughts about it.

[I-d-as]

@JamesKF some cool ideas compiled here. I was wondering what you meant by “filterable by block”. I mean I understand how the regular search pane functionality allows to search lines specifically using line:(), but I am unclear if that is what you meant.

I was and still am interested in being able to sort backlinks by headings. It is different from what you are describing, but you might be interested. Here’s a link. Option to sort backlinks by heading

Thanks

[JamesKF]

@I-d-as : Thanks for reading this and sharing your insights !

what you meant by “filterable by block”.

So, let’s say in your daily note, you have the following :

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum
• [[ProjectB]] lorem ipsum
• [[ProjectA]] #idea lorem ipsum
  • Lorem ipsum

If I go to the backlinks pane of Project A, I will get the following :

Name of the daily note

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum

---

• [[ProjectA]] #idea lorem ipsum
  • Lorem ipsum

Now, I would like to get only the backlinks related to #meeting. So in the search of the backlinks pane, I write :

tag:#meeting

But this will return the following :

Name of the daily note

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum

---

• [[ProjectA]] #idea lorem ipsum
  • Lorem ipsum

Instead of the following :

Name of the daily note

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum

Why ? Because currently, search/filter is made at page level, not block level ! So, as long as there is a #meeting in the same page as my [[ProjetA]] #idea, it will appear as search result in the backlinks pane.

What I want is to only find every block containing [[ProjetA]] and #meeting.

I hope it is more clear with this example !

[I-d-as]

@JamesKF Thanks! This totally clears things up. It also helps me realize that I have been underutilizing the search functionality within backlinks. Much appreciated.

Edit: I meant to mention that that is a great idea and workflow.

[JamesKF]

I’m glad I was able to share my idea more clearly !

To add a little precision - One could answer back that the following search, in the backlinks pane of [[ProjectA]] :

block:([[ProjectA]] #meeting)

Would make sure that I get as a result only blocks where there is both [[ProjectA]] and #meeting, right ?

Well, that query would unfortunately return :

Name of the daily note

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum

---

• [[ProjectA]] #idea lorem ipsum
  • Lorem ipsum

And not :

Name of the daily note

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum

For the same reasons explained above, that is :

search/filter is made at page level, not block level !

So, as long as there is at least one block containing both [[ProjectA]] and #meeting in a page, all [[ProjectA]] occurrences of that page will appear in the backlinks pane of [[ProjectA]].

EDIT :

It seems that in the main search (and not in the backlinks pane search),

block:([[ProjectA]] #meeting)

Will properly return :

Daily note name
-[[ProjectA]] #meeting

(But unless you expand, results are without additional context as in the backlinks pane :

Daily note name

• [[ProjectA]] #meeting
  • lorem ipsum
  • lorem ipsum

)

So it really seems we are close to getting block-level search in the backlinks pane, either by using block:() or filter through an inline tag #meeting.

[JamesKF]

@I-d-as

Edit: I meant to mention that that is a great idea and workflow.

By the way, this is how Logseq works by default : see here a kind of similar workflow, on OneStutteringMind YouTube channel.

I recently stumbled upon this very interesting video by @santi where he explains the benefits of using both Obsidian and Logseq instead of trying to fit all your workflow in a single software.

But to me, Obsidian is so close to achieving block-level search/filter in the backlinks pane, so that I can’t make my mind to use 2 different softwares.

[I-d-as]

@JamesKF Thanks again! I now have something extra to hold out hope for. I had always assumed there was no possible future in having this capability and had become accustomed to having to atomize things out to have this type of search/filtering. It surely makes for a lot of notes. Then, it also makes for a lot of extra (but sometimes very useful) steps re-comping those notes with similar others; however, losing their original context in the process. So, I have this ridiculous habit of also keeping the original source notes around and linked to the atomic children so as to have a trace back to that context should I want it at some point. Breaking up those source notes into headings per atom and embedding those headings in the atoms along with the copied text allows me to freely edit the text and eventually downgrade the embed to a link. This process will be much easier when heading edits automatically update links, at least based on my workflow. It sure is a tangled mess. But, on a positive note, I am accomplishing things impossible without Obsidian, so I am grateful. But, I surely would love to let the blocks be.

[JamesKF]

If we had block-level search in the backlinks pane, I would use the following approach with daily notes :

1. If it is a quick comment on [[ProjectA]], I just write it quickly directly in the daily note, and use a tag to be able to filter it later (#meeting, #quote, #idea, etc…).

E.g. :

• [[ProjectA]] #idea : Lorem ipsum…

2. If I have a lot to write on [[ProjectA]], I would prefer to create another note, and link to it in the daily note.

E.g. :

• [[ProjectA]] [[202201231545 - Meeting]] #meeting : Possibly a quick comment.

I still tag it as #meeting, to be able to quickly find it in the backlinks pane of [[ProjectA]]. In [[202201231545 - Meeting]], I write a link to [[ProjectA]] so that it appears in the backlinks of [[ProjectA]].

Therefore, in the backlinks of [[ProjectA]], I can find quick comments that will give context and help remember things, as well as links to more elaborated notes.

[CawlinTeffid]

Here’s another for per/note preferences (different from the linked one):

Request: toggle backlinks in document per note

Use case or problem For some notes I always want to see backlinks. For other notes, they are irrelevant. Especially on mobile, having to swipe for backlinks is a pain (pun!). If I could “toggle backlinks in document” per note, then I could set it per note and forget it. Current workaround Dataview

(EDIT: Added to original post.)

[JamesKF]

Would love any news on this FR.