+1 on making a PR, it lets us try it out, and have a feel of what can be improved, and also lets us do a code review to iron out bugs. Let us know if you need any help @alan!
1 Like
@tecosaur we can move the discussion about schema changes to another thread, but just a quick comment from me: titles aren’t actually guaranteed to be unique, so it’s not unfortunately that simple.
No problem! I’ll do that. Didn’t expect to go so far along this tangent 
This may bear on the question of brackets vs no brackets.
I’m confused on the UX.
In Roam, I think they do the brackets to avoid needing any other command to prompt for completion candidates.
Are you saying you first do the brackets, then M-r?
If yes, isn’t that redundant?
@bruce No, M-r or M-[ inserts [[roam:_]] (where _ is the point), including both bracket pairs. The difference in shortcut just brings up an ivy prompt or not (I tried making a [[ keychord but it wouldn’t bring up company for completion, so if I want company completion immediately instead of an ivy prompt I do M-[ C-SPC). I also have <tab> as part of the link’s keymap which puts the point outside of the link because I hate typing brackets that are already completed: [[roam:some link_]] to [[roam:some link]] _.
org let’s you create a link with only the prefix (no brackets) if it is only a single word; this is how org-ref uses cite: links. But since a lot of notes may be 2+ words, links ostensibly require brackets. The UX is only an aesthetic matter of whether you can see the brackets once the link is completed.
Roam may only have them as a consequence of their system design, I don’t know, but they’re there and the original goal was to mimic that (since org also requires them, visible or not). It’s coincidental that I like how they ‘group’ the link and allow two colors to be applied, but this is just personal choice – by setting some var (setq org-roam-show-link-brackets nil) a user can hide them (or set to t to show them, if consensus is nil by default).
OK, so one can’t have the same UX experience as Roam, where one types “[[” and then gets company completion candidates?
Not that I see a problem with that necessarily; just clarifying.
There’s probably a way to do it, but my first attempts didn’t work out. For some reason keychord wouldn’t call company (or company didn’t like keychord), and I didn’t find any easy alternatives to using [[ as a shortcut. That seems silly, so I would guess there’s a way to do it, I just didn’t spend much time on it after I hit that roadblock since it was only going to be a demo of possible usage.
If keychord really can’t work, then there’s probably a way to run some function on a timer or some other trigger that will fire company only if the preceding characters are [[, but that might be a lot of overhead. Or some abbrev. Surely something. Is it worth it? Meh. Company already starts after typing some number of characters anyway.
1 Like
Alternatively you could bind the [[ keychord to my ivy completion shortcut or org-roam-insert, and you would just get a completion prompt rather than company completion, which is nearly enough the same UX experience.
I have barely dipped my toes in org-roam and I can already tell this would be a super cool addition. Great work on dreaming this up!
Am I mistaken that the current linking method allows org-roam data to be freely used in other tools such as Orgzly and Beorg? That could be one unfortunate loss of a roam: protocol. I would still love it for the ability to insert links before they exist though.
There are things going on under the hood: it’s not just about typing [[. We still need a way to identify the links as being roam: links, which I believe @alan’s implementation is merely hiding. Writing a translator would be finicky, and we’d be straying yet further than the default syntax for Org-mode links.
We’ll need to have a discussion in the future between which features of Org-mode we want to keep as is, so as to guarantee compatibility with vanilla, and which we want to improve or replace for the sake of convenience.
I’m all in for easing up the process of creating links, but I think this should be done in a way that preserves the traditional format of an Org-mode file, most notably the links. Sadly, I can think of many limitations that would make this hard or inefficient, although we might be able to alleviate some of those with the db.
Let’s focus on getting a proof-of-concept out, first.
I am not experienced with either Orgzly or Beorg, but I am guessing neither can run org-roam with its database connection – rather they can just view and edit org files, and follow things like file: links. If this is the case, then yes, a roam: link would not be functional in those apps. They might (depending on their syntax checking) still identify them as links, but they wouldn’t know what to do with them.
However while you are using org-roam on emacs you would be free to edit your files with roam: links, and save them to disk with everything converted to file: links, which would enable you to use them in Orgzly or Beorg. Also, while you wouldn’t get the benefits of completions, font-locking, and checking if a note exists already or not, you would be free to simply write out the full roam: style link in the app, and update the database later – it’s just plain text after all. So you could write in the app [[roam:Apples vs Pineapples]] (not yet a functional link), save the file, sync with your computer, then open the file in regular emacs and you would have a functional roam: link. If you only have new notes, you could create them then, and if you added new links to existing notes you would have to update the OR db to grab and save them as new backlinks (easily done by just making a one char edit and re-saving the file, or simply re-building the cache).
@zaeph is correct that my demo just hides roam: in the same way that standard org links turn [[file:~/note.txt][Note file]] into just Note file. Everything is done using standard org tooling that works in vanilla emacs so long as you have a recent org release (and obviously org-roam).
Yeah, I understood that. My comment was about having the links work without Org-roam, rather than needing it to compute the destination. We’ll have to weigh the pros of usability vs the cons of efficiency (if we translate the file upon every save) and compatibility (if we don’t have proper file: links anymore).
if the links get translated from roam: to file: then other org supporting tools should continue to work. i had thought the discussion had started to entertain maintaining roam: links as @zaeph mentioned. was just thinking this morning how valuable the org consistency in org-roam is.
there are many things i would not want to move into roam and leave in org (i prefer journaling in org over dailies for example) but being able to use org “compatible” tools with roam will be great. not that i could create new roam links in the other tools necessarily but that i can access my roam archive from those tools.
1 Like
Looks like @jethro is working on an implementation which is similar to @alan’s PR, but avoids the creation of another link type.
This will have to wait until we figure out the headline insertion flow (right now, both roam: and the fuzzy links only have support at the file level. That was the main blocker for the merge.
I swear I’ll get back to this at some point! My PI is asking for 90% of our research output and I have 10% of the help I normally would, so I’m getting to work like 70 hours / week 
That and having to fix a bunch of hardware problems the last PhD left behind.
Oh no @alan don’t worry about it, the work you have done is plenty, and transferrable at least from the ux standpoint. This flow already works at the file level, but thats not sufficient for a merge.
1 Like
This is completely genius!
I come from using vim wiki where all links are created with [[ ]]
org roam is so much better than vim wiki in every sense, but this is the one feature I miss the most.
Not only this improves org-roam so much, but it also makes it easier to find a workaround conversion for converting .md to .org (In my case moving from vim wiki to org-roam)
Thank you so much for sharing this, unfortunately I don’t yet have the skill to contribute with helping programming it, but I can’t say how essential of a feature this is! Projects like this are definitely a great excuse to learn elisp indeed!
I’ll eagerly keep an eye on this!
Thank you so much