Theoretically, the number of candidates could increase a fair bit with sub-file nodes, but the current search UI only allows you to search on, and see, titles, and to see tags in the annotations.
How should this UI ideally work?
Completing-read and annotation/affixation possibilties
I’ve been working on a project to adapt bibtex-completion for completing-read, and so have been deep in the details of that, some of which might relate to org-roam v2.
The use case there is you have one or more bibtex files and you need to find and act on some candidates within.
In all of the front-end implementations (mine, as well as ivy-bibtex and helm-bibtex), the basic approach is the same:
You have a basic distinction between the candidate search string, and the display string.
EDIT: see comment below for how I concluded this was the wrong approach; but the change was trivial.
completing-read, the latter can be designated using the
The search string itself will include more data than the display string, and is actually configurable. So there’s an “additional-fields” defvar that allows you to specify which data to include in the string.
It strikes me this would make sense possibly in org-roam. It could be nice to be able to filter on content not actually displayed.
Finally, annotation and (introduced in Emacs 28) affixation.
In my implementation, I exploit this to allow the display string to be more compact, and put different types of metadata in different parts of the UI.
So here you can see the prefix contains symbols that indicate presence of associated PDFs or notes (including org-roam notes, BTW), and the suffix configurable secondary metadata.
The suffix, BTW, is defined using the affixation-function for Emacs 28, and the annotation function for pre-28, but uses the same content. Emacs will prefer the affixation function if present on 28, and ignore it on earlier versions.
The above examples are designed for vertically-oriented completion UIs. I don’t think we want that restriction for OR?
Still, some ideas could be implemented in an ancillary “annotation” package.
What does this mean for OR v2?
I think, at minimum, the UI should clearly distinguish file nodes and sub-file nodes, and on the latter, include the context of that node. If I have a section in a file called “Introduction”, just having access to the node title is not enough.
So include the title of the containing file-node in the annotation.
Aside: sometimes titles are really long. Perhaps use
Not sure whether there’s need for a prefix, and so affixation?
Anyway; I just thought I’d open this up for discussion. Thoughts?