I had written a little package called Delve to enhance the experience of “browsing” or “collecting” org roam notes (which I like to call Zettel). It’s basically a list application, where you can search the database and insert its results in the same buffer, like opening a directory in dired.
Since V2 is now taking over, I feel that this approach is not working anymore. If you can have result sets with thousand nodes (=Zettel), it does not make sense to list them in a buffer.
On the other hand, I feel the need to have some kind of “entry point” or “dashboard”, and I am sometimes dreaming of a simple way to collect notes by quickly adding them on a stack (which was one of the basic functionalities of the soon-to-be-outdated package mentioned above). But then, I feel that org roam links can most easily and most powerfully handled in org mode buffers, which is actually what I do when I collect stuff and work with my notes. And it works fine.
So my question is: Do you guys see any need for a kind of “dashboard” entry point, or something to explore the Zettelkasten, and what exactly do you think would be needed? Do you miss some functionality of that sort, and how would you want to integrate it into your workflow? I need some ideas to move Delve to the next level, or to abandon it. Interested in your thoughts!
I have personally found index notes to be pretty effective for this. An index note is basically a not that doesn’t have its own content, its only purpose is to link to other notes. I use them to create entry points into different parts of my notes. The advantage of these manual indexes is that I can put some text around each link, and curate them so that only relevant links are there.
Of course to create index notes I have to browse my notes, so I could definitely see a use case for a package that makes it easier to find stuff.
I don’t think so? An initial listing of index notes could also be an index note. It’s more that in order to create an index note I need to find what should go into the index note, so having a tool that helps with that would be useful.
But how would you collect these links? Won’t you just insert them in the newly create note file? That’s what I too when I collect notes for a project. I see no real need for an extra tool.
As I understand your package, it provides functionality for browsing your notes by using some custom searches and generally providing useful meta data. I think that could help me find notes that I want to put in my index files. Yes, I will just insert links to the interesting notes in a new note file, but I have to find which notes to link to first which is where something like your package could come into play.
You understand the current package perfectly, and my point is exactly that this kind of “searching” does not seem to be feasible anymore. Searching becomes quite complex: “search for all notes matching xy in the title, tagged with z, but not with y”, etc. And most of all, searching can be done easily in the completion interface (I can even negate tags using orderless completion style). So it does not look really helpful to me anymore to do some searching in any other way than using the completion UI.
Of course, if you still think that would be useful, I’m glad to hear that; this kind of feedback is exactly what I am looking for. I might just be lacking imagination for a use case.
One thing that stood out to me, that could fit well with upstream (i.e. org-roam) is the thing that indicates how many links and backlinks a note has. I think that could fit well into the backlink buffer (at least how it looks like in v1, but I think it should apply to v2 too).
Hi! Kind of old topic, but I absolutely share your intuition for wanting to create better overviews/entry points into my notes. @KirillR and I just published org-roam-ui which aims to do exactly does this. At the moment it’s just the graph but we aim to do much more than that and I would love to have your feedback on how and what to present. I personally thought Delve was a great package, and I would like to recreate some of that functionality in orui.
Thanks for pinging! I saw org-roam-ui, it sounds like a great thing! Impressive! Can’t test it, however, since I still have Emacs 27 (it says “>27” in the requirements).
Regarding your question, I am still undecided. What should be main entry points? Don’t know, since there are many possible answers. I think the ideal solution would be to have something similar to “org-ql”: A query language which allows to easily define entry points of one’s liking. I am dreaming of a query like “show me all nodes with a certain tag which I have modified the last week, plus all of those whose tag matches the string ‘dashboard’”… But defining such a query language is too far away for me right now and for my limited computer skills; I couldn’t find an intuitive way to translate sexp’s into solid sql statements.
Another way to define “entry points” could be to interact with “org-roam-ui”: the user collects nodes and puts them in a separate list, which then can be kept persistently. Kind of like bookmarking when browsing. Or is this already possible?
Using a graphical selector for creating “interesting lists” actually sounds like a good use case to me and might even bring me back to working on Delvev2, since such a use case could not be replaced by simply creating a new index Zettel. So maybe that’s the way to go?
Whoops, that’s my bad, it should have said Emacs >= 27! Emacs 27 works perfectly fine, maybe even 26 would work.
@KirillR has also been toying with this idea of an “org-roam-ql”, and I think that that would be the best solution in the end, but this would obviously require quite a bit of work as it (probably) need to be compatible with SQLite, which sounds like a pain to make userfriendly.
The “bookmarks” thing is something I definitely want to implement, sooner rather than later! Do you think it’s important that this work well with the Emacs-side of things, e.g. be able to display a list of these lists in org-roam? Maybe for that some tighter integration with Delve would be great.
Ah good, if iorg-roam-ui is compatible with Emacs 27, I’ll try it out soon. I can also imagine aiming at a good integration of the bookmarks functionality. As I understand, it’s currently possible to switch from the graphical representation of a node to its real text pendant. So we’d just need to add some extra magic on the Emacs side after that move, something akin to “register this as a bookmarked item”. Such a functionality would be useful in any case, and it would make sense to be accessible from within a node in an Emacs buffer, independently of how this node has been reached.
Another idea would be to use the existing bookmark functionality, which can easily be extended. But I would dread my bookmark list to be cluttered with all kind of nodes, so it might be wiser to keep things separate…
So what about that: you teach org-roam-ui to do something with a node on demand (like a hook, with its UUID as sole argument), and the fall back functionality would be something like just plain old bookmarking that node. On the Delve side, I could optionally allow the user to replace that default functionality with a Delve list collector. This way, there would be no strong dependency, but a nice possible integration.
Sounds good! And luckily org-roam-ui already has the functionality to (basically) trigger any arbitrary action in Emacs as Emacs is serving as a WebSocket server. I could just tell org-roam-ui that, on a node action, do X in Emacs!
And I think I’m mildly lost what kind of bookmarking we are talking about haha. I was thinking of it in this sense: be able to compile the list of nodes currently in view in org-roam-ui (should not be too difficult) into some sort of list, which we pass onto Emacs. This list could then be used in Delve as well to browse this list just in Emacs.
Ideally this behavior could work the other way around as well, but I’m not sure if you know how to/want to implement that on your side.
But we could also definitely do what (I think) you mean, namely that when clicking (or whatever) on a node in org-roam-ui, this would automatically get added to some sort of bookmarking list in Delve, is that right?
Yes, that seems to be the core functionality. Don’t know, however, how much sense it makes to collect a whole list first in orui to pass it then to Delv2e, this could mean too much duplication of functionality. I just thought of as “click on it, and it’s saved as a bookmark on the Emacs side”.
I was thinking about C-x r b and C-x r m and friends. I use it to bookmark all kind of Emacs objects: Files, dired buffers, mails… It’s easy to add bookmarking of “nodes” (and I am sure somebody has already done that, since it is basically bookmarking of org mode headings). Calling C-x r m lets you add a bookmark, C-x r l shows you a list, C-x b lets you jump to that bookmark. So if we think of the action as “bookmarking”, why not using the built-in functionality?
Just to follow-up on my own last post: I’ll post an issue at github once delve v2 is ready for such a bookmarking feature, we can continue discussion there. Might take a while, though.
Visually, it would look kind of like the image below. It’s a rudimentary “mock up” to convey the idea I am going for… The idea is simple:
Pin relevant nodes. As you walk through your nodes through the graph or Emacs forward- and back-links, you “pin” nodes of your interest.
Produce a list of pinned nodes. I have been thinking of a dedicated section. It can be further enhanced by Delv’s powerful list capabilities
Generate a list of transclusions from the pinned nodes. This helps you quickly assemble a draft of your article – add more writing and re-organize the draft
What do you think? Looking at your discussions, this does not seem too off the mark. The pinned node buffer is essentially a variant of “bookmark”, isn’t it?
Below is my quick-and-dirty prototype code for this idea.
YES! That sounds amazing, I love it. I think this could exist separately from the Delv integration, as these pins could be directly transfered from org-roam-ui (I think that might be easier to manage). But in general I LOVE this idea, this really seems like it would make Zettelkasten a productive tool. I often struggle with a) finding the relevant notes and b) putting them in a bigger file in a sensible way, and this seems like the perfect solution.
However, I think we should think about the UX of this somewhat carefully, would you be interested in having a chat about this with me and perhaps @KirillR ?
Also, how does org-transclusion handle links atm? One of the things I struggled with with using it was that it did not leave a link (maybe you prefer this). But with org-roam-ui with could potentially solve this as we add a ton of fake links already. If we somehow have a way of keeping track of transclusions then this would really be my dream application.
In any case, I’m all for this collab! One of the reasons I personally wanted to start org-roam-ui was because I wanted a platform where a lot of individual org/emacs packages could be unified. I love emacs and I love putting things together myself, but sometimes it’s nice when someone has already prebuilt something that works really well. Love it
I agree that the UX should be designed carefully and work really well – I will be happy to chat with you both and perhaps iterate; we may not get the UX right from the first instance.
At the moment, a transclusion is defined by a keyword, not a link in the Org syntax like this:
Org-roam does not cache these, of course; but it should be simple to add an extension to bridge Org-roam and -transclusion.
I am also interested to experiment to see what is a better “way of keeping track of transclusions”.
No, I don’t do research. I just read some of these things on the side. These are just examples, not my real notes; I guess they show my aspirations. It’s just my personal preference to use them, which would be closer to what I would use, than the usual “foo” and “bar”, which I will never have in my real notes.
