Last thing I wanted to mention: I’m currently working on a query system for org-roam-ui in order to have very extensible filters, rather than just filtering based on tags and some predefined toggles.
Harking back to the “integrating well with other org-packages” above, I would like to make this querying system as interoperable as possible with other org-packages, and I think Delve would be a fit for such a system. You already have some sort of query system, although I could not really figure out how extensible it is, can you only set these using the delve-dashboard-tags variable?
I would really like to be able to query the org-roam-db, or, more accurately, get a list of nodes from that database, without using SQL, but something more like org-ql or like Roam Research query blocks. I would see this used in three situations:
- In org-roam-ui, obviously, as I want to use it to create filters.
- In Delve, to easily define a list of nodes to view/safe
- In @nobiot 's
org-translusion, to insert a (preview of a) list of nodes in any org-roam-buffer, to emulate Roam Research’s source blocks.
I think these are very feasible things to do, and I have already made some sort of system for org-roam-ui, but I would ideally like
a) us to use the same syntax
b) for these “blocks” to be as interoperable as possible
This would be such an asset to the org-roam ecosystem! Especially being able to view the nodes as filtered by date (plugging my own org-roam-timestamps) and links would be great, such as “give me all nodes which link to X and Y created after ZZZZ with tag W”. Delve would be such a fantastic way to visualize that (really great job on the ui side btw, love the icons).
The way I currently have the queries implemented is using the following syntax:
bare_words_for_titles title:(this filters titles) tag:(some_tag, another_tag) dir:(subdir) file:() ctime:() mtime:() query:(name_of_another_query)
Obviously not very lispy, kind of ideosyncratic and just kind of cumbersome. The actual syntax does not matter that much to me. Roam’s syntax is something like {{query: {and: {property operator value}}}}, people use that all the time.
What is important is that we use the same syntax, otherwise there’s not really a point to having this shared.
What are you guys’ thoughts? I really want to implement this and would probably end up making some pull requests for org-transclusion and delve to add these features, but I don’t want to ideosyncratically decide this, nor do I think I understand your packages as well as you do and whether this would be feasible at all!
Here are some threads which have touched on this idea as well: