Roam-ref protocol on Windows

Troubleshooting
1

Using org-protocol as mentioned here and set up on Windows as mentioned here after opening the URL org-protocol://roam-ref?template=r&ref=test&title=test in the browser, I am put into an empty Emacs buffer with the file name c:/Windows/system32/org-protocol:/roam-ref/?template=r&ref=test&title=test-title.

I also did edebug-defun on org-roam-protocol-open-ref and it seems it is never called. Any hints on how to further debug this?

Update: This might be solved after reading the upcoming chapter in Zero to Emacs and Org-roam: a step-by-step guide on Windows 10

1 Like
2

@fleimgruber, copying what I wrote here to have a dedicated thread for your issue.

It seems to work on my PC without the “tricks” I am writing in the new chapter.
Two things worth checking:

  1. Have started Emacs Server? – e.g. M-x server-start
  2. Have loaded org-protocol and org-roam-protocol? – e.g. M-x load-library

Alternative to M-x, you can put this in your config.

(server-start)
(require 'org-protocol)
(require 'org-roam-protocol)

image
image1432×1286 55.9 KB

3
  1. Have started Emacs Server? – e.g. M-x server-start

It is running at all times.

  1. Have loaded org-protocol and org-roam-protocol ? – e.g. M-x load-library

Yes, using the same emacs-lisp as I used under Linux where it works.

I am suspecting that Emacs is not able to create the file for the buffer c:/Windows/system32/org-protocol:/roam-ref/?template=r&ref=test&title=test-title since that would require Administrator privileges. I would expect the buffer name to be prefixed with CAPTURE-test.org and something goes wrong even before any org-roam code is called (as I mentioned with my attempt to edebug-defun above).

4

Gotcha: https://github.com/sprig/org-capture-extension/issues/41#issuecomment-578499266.

The issue goes away if I use a single slash, i.e. org-protocol:/....

1 Like
5

Wow… Good to know!

But… it’s strange. This does not explain why mine works as below:

  1. Pasting this in my Firefox address bar just works – double slash: “org-protocol://roam-ref?template=r&ref=test&title=test”
  2. It tries to create a file in my org-roam-directory with the extension I specify .md
    image
    image1856×658 14 KB

For 1, I am not sure – I have some idea to test…
For 2. not sure if this is the same as how yours behave.
Actually, 1 may be related to 2 (something related to what I am writing in the chapter…).

I guess we don’t have to delve too much into this for now?

What’s your Org Mode version? 9.3.6?
(M-x org-version).

6

Just quickly, if your Windows is on Org Mode 9.3.6, and do edebug-defun on org-protocol-check-filename-for-protocol in org-protocol.el, you might hit it from Firefox.

Here is my hypothesis for your case:
The function is the cause of the issue with the parameter returned from Chrome (not Firefox) not recognized by org-roam-protocl-file – your case with ref with Firefox may be caused by the same issue – it’s the regexp in this function that does not properly parse the parameter. Hence, the entire string of org-protocol://roam-ref?template=r&ref=test&title=test gets considered as a single filename (and the forward slash considered as a path delimiter) – and in your case, Emacs tries to create a file in your “default” folder, “c:/Windows/system32/”.

Just a thought. I could be totally wrong…
This does not explain why your Linux works – maybe it’s on Org Mode 9.4, which has fixed this issue.

7

What’s your Org Mode version? 9.3.6?

9.3.7

do edebug-defun on org-protocol-check-filename-for-protocol in org-protocol.el , you might hit it from Firefox

As I wrote, it is only called (and then debugged) if I use a single slash.

Chrome (not Firefox)

I can reproduce this without any browser, e.g. just with the URL handling of Windows.

start "" "org-protocol:/roam-ref?template=r&ref=test&title=test"

start "" "org-protocol://roam-ref?template=r&ref=test&title=test"

This does not explain why your Linux works – maybe it’s on Org Mode 9.4, which has fixed this issue.

I am pretty sure it is 9.3.x there. But I think ultimately it is about the URL handling of the OS coupled with Emacs specifics that is more sane there.

Here is my hypothesis for your case

The issue comment I linked to above describes well what is going on here as far as I can tell.

I guess we don’t have to delve too much into this for now?

Yes, my workaround is just to have another bookmarklet that uses a single forward slash.

Thanks for thinking along!

1 Like
8

No worries. Thank you; I have learnt a new trick. Not intending to drag you any more (let’s enjoy our Friday).
I think you are right – it should be a combination of OS handling URL and Emacs (Org Mode).

I have managed to repro your issue with Org Mode 9.3.6 – it is fixed in 9.4 (Doom gets it for you).
This is part of the thing I’m writing in the chapter to fix the Chrome issue for org-roam-protocol.

image
image2985×1522 353 KB

: Screen shot of cmd and edebug session on org-protocol-check-filename-for-protocol

Note that the string-match returns nil. This led me to an empty buffer.

It’s in org-protocol-check-filename-for-protocol (way before org-roam-protocol-open-ref).

It’s the same problem that Chrome suffers.

Anyways, have a great weekend!

9

Ah, thanks for sharing the journey. Regarding org-protocol-check-filename-for-protocol, yeah that is the one, see again the first Edit in https://github.com/sprig/org-capture-extension/issues/41#issuecomment-578499266.

1 Like