(feat): filter by nodes containing links

[natask]

Table of Contents

1. Goal
2. Implementation details
   1. How will the user use this feature?

based on comment

Goal

The goal is to narrow down nodes by the links they contain (forwardlink) or narrow down nodes by nodes that link to them (backlink).

Implementation details

org roam url does this already. need to utilize its methods.

I propose using dest: and destination: to narrow to nodes that contain link and source: to narrow to nodes that are linked by node. In the future can define dest1: to destn: where n is a number that matches nodes that are n edges away from node and destall1: to destalln: that matches nodes that are between 1 to n edges away from node.

How will the user use this feature?

It is not straightforward for the user to find a nodes id before searching using it. I am thinking multi org-roam-search sessions. For example, imagine the user is looking to find nodes linked to by node1 and node2. He opens a org-roam-search session. He types in dest:, then creates a new session where he filters down to and selects a list of nodes, he executes a command that takes the ids of the selected nodes and formats them as id1,id2. He is then dropped back to the previous org-roam-search session where he pastes the results. In such a way, the user can construct arbitrarily complex searches that depend on many different nodes.

A wrinkle is helm is the only completion framework currently supported. Helm doesn’t support multi helm sessions well (helm-resume). vertico does so but its support can be improved. opening new vertico sessions is possible. That is all that is necessary for the above. however I am not sure how easy is to manage these sessions. It would be useful to switch between open sessions. as a side point, I know that only a single closed vertico session can be found in vertico-continue.

If queries speeds are improved as per the following thread and view tables are merged into org-roam, then can easily support multiple completion frameworks because filter and sorting can be done within emacs with satisfactory performance.

For now, the user would need to open each node, get the id and then use it in subsequent search.

I can implement an action for helm that grabs and formats and places in kill buffer the ids of selected nodes. Then these ids can be accessed in future helm sessions from the kill ring.

[wuqui]

This looks really promising. I'm excited to try it 🙂

I've had a conversation with the author of vulpea who has implemented an (interactive) function to search for shared backlinks. I'm gonna reference it here in case you find it interesting: https://github.com/d12frosted/vulpea/discussions/106