Org-super-links with org-roam

How To Requests
1

Hello everyone,

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:
    1. create a link with (org-roam-node-insert)
    2. 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.

1 Like
2

Personally I’d dislike the approach for the following reasons:

  • putting a link to a different note is a conscious decision and for regular notes (not structured notes or MOC’s) I add context to why it’s linked
  • using the backlink as a way to explore currently incoming links and as long as I deem it not important enough to link back and make a circular dependency due to missing context it stays as a backlink

Then again, if this integration is optional, I wouldn’t mind.