Re: Bug: Org manual, 16.15.2 The ‘capture’ protocol, possible error [9.4.4 (release_9.4.4 @ /home/admin/Programming/Software/emacs/lisp/org/)]

[Maxim Nikulin]

On 21/03/2021 14:04, Jean Louis wrote:
>  >       emacsclient 
org-protocol://capture?template=X?url=URL?title=TITLE?body=BODY

Certainly extra question marks should be replaced by "&".

> emacsclient 'org-protocol://capture?template=X&url=URL&title=TITLE&body=BODY'

However I am in doubts if such form with double slash should be 
recommended if org-protocol scheme is registered in desktop settings. 
Subprotocol "capture" could be parsed as host name before passing to 
handler. With old syntax and colon after subprotocol the problem was 
more severe:
https://github.com/sprig/org-capture-extension/issues/16
Colon in some desktop environments may be dropped since port number 
after it is not specified. It seems with new syntax a similar problem 
could happen as well:
https://code.orgmode.org/bzg/org-mode/commit/928e67df
These complications are irrelevant if org-protocol URI is passed 
directly to emacsclient bypassing desktop handlers.

Is any problem expected with single slash after the scheme?

org-protocol:/capture?template=X&url=URL&title=TITLE&body=BODY

Alternatively 3 slashes could be used in examples:

org-protocol:///capture?template=X&url=URL&title=TITLE&body=BODY

I hope, "capture" in both variants is parsed as part of path, so it is 
safer. On the other hand I could not test on Mac and Windows. Even some 
linux distribution could be some specific.

Such change could be committed in optimistic way if nobody will object, 
not requiring to confirm that it works on every OS.

A have a couple more questions.

Is it intended decision that no leading slash is not allowed?
org-protocol:capture?template=T&...
In my opinion it is similar to mailto: scheme, so subprotocol should not 
be considered as hostname.

Is there any reason that space can not be encoded as "+"? It is allowed 
in query URL part and it prevents direct usage of modern API available 
in JavaScript:
String(new URLSearchParams({template: "X", url: "https://orgmode.org/";, 
title: "Org mode"}))
"template=X&url=https%3A%2F%2Forgmode.org%2F&title=Org+mode"

I guess that decoding of "+" just was not necessary in old syntax since 
all parameters were encoded as path components. Could anything bad 
happen due to update of decode function to allow "+"?