I’m currently trying to combine org-roam with org-super-links, and I’m looking for some feedback on this workflow and I believe it might be interesting to some other people as well.
What is org-super-links?
org-super-links solves the same backlinking problem as org-roam in a different way. Let’s assume we have File A and we link it to File B.
org-roam inserts a link in File A and using the db we can see this backlink in File B in the roam buffer
org-super-links doesn’t use a db. It also inserts a link in File A but at the same time, it inserts a backlink into File B, putting it in a user defined drawer. (It is also possible to delete both sides of the link with a single command)
Downsides of org-roam:
- the backlinks don’t work in an environment where you can’t access the db, making the notes less portable (e.g. mobile, other emacs config)
- personally i’ve never been the biggest fan of having the backlinks in a separate buffer
Downsides of org-super-links:
- without a db it is really slow to add a link to an existing note (however an existing uni-directional link can be instantly converted to a bi-directional link)
- you don’t get all the benefits of having a fast queryable db and other extensions like org-roam-ui etc
How to combine the two?
- there are multiple ways but one very easy workflow is this:
- create a link with (org-roam-node-insert)
- convert this link with (org-super-links-convert-to-super)
- it would be trivial to combine this in a single function
- (at the moment this only works when the target id belongs to a headline and not to a file, but it shouldn’t be too hard to fix this)
Advantages of this workflow:
- all your connections are visible in collapsible drawers and the roam buffer is optional
- there is always a slight delay when opening the roam-buffer, having the backlinks saved in the file buffer avoids this
- you still have all the performance benefits of the org-roam-db and can use it’s extensions
- your backlinks are still usable without org-roam
- you could use both single links, and super links to create different relations. super-links would be more like connections and saved in the file buffer and single links would be like a parent-child connection, visible in the roam buffer
A small downside:
- org-roam-graph creates two arrows between connected notes and can become quiet cluttered (org-roam-ui handles this better, by showing a single arrow pointing in both directions, would this also be possible in org-roam-graph?)
And finally one big open question I have, and my main reason for writing this:
How would this affect performance and does this approach scale?
For now I only tested this with a handful of notes and it works great, but essentially this doubles the number of links in the roam-db and every connection ends up being a circular reference.
So I was wondering, if I might run into some trouble down the line, when implementing this approach.
Also I’m happy about any feedback about this workflow, I haven’t commited to it yet, but I do believe this can be a quiet powerful combination.