We could drop the user-error form…
https://github.com/jethrokuan/org-roam/blob/6175739b33b0abaa862c0137e216e6029f24d5cd/org-roam.el#L325
…and change it to a cond check to insert absolute paths.

At first, I was on the fence because I think that org-roam-insert should specifically work with org-roam files (i.e. inside org-roam-directory. After all, we can use org-store-link to get a link to the file. Problem is, if org-before-first-heading-p is t, we would only get the file-name, which might not be very informative.

We could create a new link-handler for org-roam which would fill the visible part of a link with the #+TITLE of a note. We might also want to avoid the usual behaviour which, when org-before-first-heading-p is nil, would link you to the nearest parent heading.

We could drop the user-error form…

https://github.com/jethrokuan/org-roam/blob/6175739b33b0abaa862c0137e216e6029f24d5cd/org-roam.el#L325

…and change it to a cond check to insert absolute paths.

I agree, I think removing the user-error is all that's needed. I don't think a check for absolute paths is needed because of the file-relative-name here: https://github.com/jethrokuan/org-roam/blob/master/org-roam.el#L316

Happy to make a PR if you are happy with that.

At first, I was on the fence because I think that org-roam-insert should specifically work with org-roam files (i.e. inside org-roam-directory. After all, we can use org-store-link to get a link to the file. Problem is, if org-before-first-heading-p is t, we would only get the file-name, which might not be very informative.

We could create a new link-handler for org-roam which would fill the visible part of a link with the #+TITLE of a note. We might also want to avoid the usual behaviour which, when org-before-first-heading-p is nil, would link you to the nearest parent heading.

This would also be good. I've got this working in a previous notes setup (although using a custom link type, so might not be exactly the same) so could contribute another PR if that would be a good fit here.

Another nice org-link customisation would be to show the title on hover instead of the filename.

I agree, I think removing the user-error is all that's needed. I don't think a check for absolute paths is needed because of the file-relative-name here: https://github.com/jethrokuan/org-roam/blob/master/org-roam.el#L316

You're right; I'd misread the path when I ran tests.

Happy to make a PR if you are happy with that.

It's not up to me. Let's wait to see what @jethrokuan thinks about it first.

This would also be good. I've got this working in a previous notes setup (although using a custom link type, so might not be exactly the same) so could contribute another PR if that would be a good fit here.

Another nice org-link customisation would be to show the title on hover instead of the filename.

Same as above: hold off for now in case we decide to maintain the original behaviour. We might be missing something.

Sure.

I suppose even though a relative path would work from an external file, an absolute path might be preferred in case the external file is moved?

Another option (which I was using before) was to use a custom link type which is relative to the org-roam directory -- so a file called 20200416191822-slug.org could be referred to from anywhere by the link [[roam:20200416191822-slug.org]]. That would be useful in external files (1) if the external files might be moved and hence break relative links, or (2) if the absolute path to the org-roam directory might change (e.g. on different machines).

(a custom link type would work within org-roam-directory too but isn't so necessary because relative paths work fine)

Uhm, I don't know. I think one of the reason why we aren't explicitly supporting external links to files inside org-roam-directory is that, within the confines of org-roam-directory, we can manage the backrefs and ensure that links remain consistent, even when the files are renamed. org has some rudimentary ways to deal with it with :ID: and :CUSTOM_ID: for headers, but not for files.

Anyway, it's a whole different problem. If you want to create a short-lived tasks to do something on a note, like rewrite a passage, I've found contextual org-capture with %a to be enough.

Happy to make a PR if you are happy with that.
It's not up to me. Let's wait to see what @jethrokuan thinks about it first.

I'm okay with removing the user-error, I can see the use-case of inserting org-roam links in files outside of org-roam. Not sure how useful it will be, as it may insert a rather ridiculous relative path.

Another option (which I was using before) was to use a custom link type which is relative to the org-roam directory -- so a file called 20200416191822-slug.org could be referred to from anywhere by the link [[roam:20200416191822-slug.org]].

This I'd rather not, as without org-roam things would no longer function. As much as possible, I'd like to keep the Org syntax familiar and simple.

I'm okay with removing the user-error, I can see the use-case of inserting org-roam links in files outside of org-roam. Not sure how useful it will be, as it may insert a rather ridiculous relative path.

I'll make the PR now, then.

Thank you both, sounds good to me.

Just one more thought: now is the chance to choose whether you get relative or absolute links from outside the org roam directory, without making a breaking change, since neither was possible before. I’m not sure which is best, so probably fine as is.