emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Maxim Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: 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/)]
Date: Wed, 24 Mar 2021 22:31:00 +0700	[thread overview]
Message-ID: <s3flvl$a48$1@ciao.gmane.io> (raw)
In-Reply-To: <868s6hvvfs.fsf@protected.rcdrun.com>

On 21/03/2021 14:04, Jean Louis wrote:
>  >       emacsclient 

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:
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:
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?


Alternatively 3 slashes could be used in examples:


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?
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"}))

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 "+"?

  reply	other threads:[~2021-03-24 15:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21  7:04 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/)] Jean Louis
2021-03-24 15:31 ` Maxim Nikulin [this message]
2021-03-28 16:35   ` [PATCH 1/2] org-manual.org: Fix typo in org-protocol capture example Maxim Nikulin
2021-03-29  4:39     ` Kyle Meyer
2021-03-28 16:38   ` [PATCH 2/2] Add quotes to emacsclient arguments in examples Maxim Nikulin
2021-03-29 16:29     ` Maxim Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='s3flvl$a48$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).