You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would place a link to a node in a deeply nested, large .org file with many headings, here's an example with a datetree structure:
* 2026
** 2026-02 February
*** 2026-02-02 Monday
......
****** How reading changes the way your brain works
[[Neurobiology]] [[youtube]]
*** 2026-02-05 Thursday
******* Stop Writing Dead Programs by Jack Rusher
[[youtube]]
....
.etc.
Now, in order for the (vulpea-find-backlink) to work and properly navigate to these nodes, one has to have them indexed, i.e., they must have IDs. However, very often you either explicitly don't want them indexed, or simply don't bother adding IDs. Yet, we should be expecting the backlink finding UI to allow you to find them, and, with consult integration to be able to preview the headings - it should automatically expand to reveal the context around the link (with consult-preview-key or automatically - if consult set to preview).
I have to note that Org-Roam doesn't support that either and I had to add some hacky customizations around it - which still is pretty naive - it only navigates to the first found link, meaning - if I'm searching for backlinks to [youtube] node, it can only navigate to the first item.
It would be nice to think of a better way for this scenario.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This this the actual use case I have.
I would place a link to a node in a deeply nested, large .org file with many headings, here's an example with a datetree structure:
Now, in order for the
(vulpea-find-backlink)to work and properly navigate to these nodes, one has to have them indexed, i.e., they must have IDs. However, very often you either explicitly don't want them indexed, or simply don't bother adding IDs. Yet, we should be expecting the backlink finding UI to allow you to find them, and, with consult integration to be able to preview the headings - it should automatically expand to reveal the context around the link (withconsult-preview-keyor automatically - if consult set to preview).I have to note that Org-Roam doesn't support that either and I had to add some hacky customizations around it - which still is pretty naive - it only navigates to the first found link, meaning - if I'm searching for backlinks to
[youtube]node, it can only navigate to the first item.It would be nice to think of a better way for this scenario.
Beta Was this translation helpful? Give feedback.
All reactions