[PATCH] Fix FAQ entry about mailto links.

[PATCH] Fix FAQ entry about mailto links.

[Robert Goldman]

The old entry referred to the variable =org-link-mailto-program= which
was removed from org-mode almost eight years ago!  See org-mode commit
b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb
---
  org-faq.org | 18 +++++++++++++++---
  1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 4b34560c..cac8063e 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
  #+index: Link!Mailto

  You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+changing the entry for =mailto:= links in =org-link-parameters=:

-=M-x customize-variable org-link-mailto-program=
+=M-x customize-variable org-link-parameters=

  The default function called is =browse-url=, which opens a mail
  composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
+=browse-url= depends on the setting of the variable =mail-user-agent=.
  Thus, if you want to ensure that mailto links use Gnus to open a
  message buffer, you could add the following to your =.emacs=:

@@ -1941,6 +1941,18 @@ message buffer, you could add the following to 
your =.emacs=:
  (setq mail-user-agent 'gnus-user-agent)
  #+end_src

+You can also change the function used to a different one.  For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
+
+#+begin_src elisp
+("mailto" :follow
+      (lambda
+        (path)
+        (shell-command
+         (format "open -a MailMate 'mailto:%s'" path))))
+#+end_src
+
  ** Can I use CamelCase links?
     :PROPERTIES:
     :CUSTOM_ID: CamelCase-links
-- 
2.31.1

Re: [PATCH] Fix FAQ entry about mailto links.

[Max Nikulin]

On 07/01/2022 01:34, Robert Goldman wrote:
> 
> The old entry referred to the variable =org-link-mailto-program= which
> was removed from org-mode almost eight years ago!  See org-mode commit
> b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb

Unfortunately FAQ has a lot of obsolete recipes. Generally it is great 
when answers are updated with contemporary info. I have a couple of 
questions concerning your patch though.

> diff --git a/org-faq.org b/org-faq.org
> 
>   The default function called is =browse-url=, which opens a mail
>   composition buffer within Emacs. The type of buffer opened by
> -browse-url depends on the setting of the variable =mail-user-agent=.
> +=browse-url= depends on the setting of the variable =mail-user-agent=.

[[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] link to the Emacs 
manual might be used. I am unsure however if it is really necessary.

> +You can also change the function used to a different one.  For
> +example, the following function (on MacOS) opens =mailto:= links in
> +the =MailMate= program:
> +
> +#+begin_src elisp
> +("mailto" :follow
     ^
It seems, `org-link-set-parameters' is missed. I am not an experienced 
emacs user, so my question may be naive. There is 
`browse-url-mailto-function' since Emacs-24.1 that should be called by 
`browse-url'. Is there a reason to avoid its customization instead?

> +      (lambda
> +        (path)
> +        (shell-command
> +         (format "open -a MailMate 'mailto:%s'" path))))
> +#+end_src

Shell commands require a lot of care otherwise they become an open door 
to security vulnerabilities. I am a linux user and I have tried a dialog 
application instead of real mailer for a test:

---- >8 ----
#+begin_src elisp :results silent
(org-link-set-parameters
   "mailto" :follow
	(lambda
	  (path)
	  (shell-command
	   (format "zenity --info --no-markup --title 'org mailto: test' --text 
'mailto:%s'" path))))
#+end_src

[[mailto:Hacker '`mktemp mailto-vulnerability.XXXXXX`' <hack@te.st>]]
---- 8< -----

Following the link (C-c C-o) caused creation of a file in the current 
directory.

Arguments to shell should be at least passed through 
`shell-quote-argument'. A better way is to use more verbose function 
that accepts arguments as a list and directly executes the binary 
without interpreting anything by shell.

Another problem that the command above blocked emacs session. I do not 
know a reliable way to launch a detached process from emacs. When 
someone adds a code that should perform such task, it usually suffers 
from a decade-old bug 
https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html 
Current code in `mailcup-view-mime' and in `org-open-file' suffers from 
at least three other problems: I do not know anything about first one 
besides that it is somehow related to compatibility, another one assumed 
to be rather rare, third one is that the process have to be killed on 
exiting from emacs.

So, I hope, `make-process' is better than `shell-command', but a 
specific application might make emacs CPU hungry.

A recipe having security issues, in my opinion, is worse than no example 
at all.

Re: [PATCH] Fix FAQ entry about mailto links.

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Robert,

Thank you for pointing out that `org-link-mailto-program' should not be 
recommended in FAQ any more.

I prepared an alternative patch that recommends to customize Emacs 
variables at first. I hope, an example is safer now, however I can not 
test it on MacOS. Could you, please, review the patch, since I may miss 
something important from your point of view?

On 07/01/2022 18:03, Max Nikulin wrote:
> On 07/01/2022 01:34, Robert Goldman wrote:
>>
>> +You can also change the function used to a different one.  For
>> +example, the following function (on MacOS) opens =mailto:= links in
>> +the =MailMate= program:

I am unsure if MailMate is acceptable since it is a proprietary 
application. Org is a part of *GNU* Emacs, so it may be better to 
mention some free mail user agent.

>> +#+begin_src elisp
>> +("mailto" :follow
>      ^
> It seems, `org-link-set-parameters' is missed.

I am sorry, I missed that you suggested to customize the 
`org-link-parameters' variable, so function call is not necessary here.

[-- Attachment #2: 0001-FAQ-Update-suggestion-for-mailto-link-handlers.patch --]
[-- Type: text/x-patch, Size: 5869 bytes --]

From 2ace01016588884f61361b6f37bf3273f8520f2c Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Mon, 7 Feb 2022 23:40:37 +0700
Subject: [PATCH] FAQ: Update suggestion for mailto: link handlers

org-faq.org (mailto-links): Mention `org-link-mailto-program' as removed
variable, recommend customization of `browse-url-mailto-function' or
`org-link-parameters' instead.

Robert Goldman <rpgoldman@sift.net> in
https://list.orgmode.org/FEAD92A6-87DE-4CFF-8459-E3D012DD3F52@sift.net
proposed a patch removing mention of `org-link-mailto-program' variable
that is not used in the code for some time.  The patch has an example of
usage `org-link-parameters' to assign custom external handler for
mailto: links.

This change recommends to configure Emacs facilities used by Org as
well.  It has a safer example for `org-link-parameters' customization.
---
 org-faq.org | 87 ++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 76 insertions(+), 11 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 4b34560c..b6bde3ca 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1926,21 +1926,86 @@ For example:
 
 #+index: Link!Mailto
 
-You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+Org calls ~browse-url~ function for =mailto:= links, so it should obey
+your Emacs configuration.  If something goes wrong then
+[[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good starting point.
+
+By default mail is composed in an Emacs buffer.  If you prefer some
+external application instead than set ~browse-url-mailto-function~ to
+nil, e.g. using
+[[elisp:(customize-variable 'browse-url-mailto-function)][=M-x customize-variable RET browse-url-mailto-function RET=]]
+and =mailto:= links will be opened accordingly to
+~browse-url~browser-function~ value.
+
+If you intention is to compose messages in Emacs then consult
+[[info:emacs#Mail Methods][info "(emacs) Mail Methods"]].  Check that ~browse-url-mailto-function~
+has its default value ~browse-url-mail~.  Emacs has several mail
+packages, so next step may be
+[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]] to set the variable
+to e.g. =gnus-user-agent=.
+
+If you prefer an external application other than configured in desktop
+environment then you should write a custom URL handler function.  Be
+careful, try to avoid shell (e.g. ~shell-command~ function) since it
+is easy to mess up with escaping of the URL argument and thus to allow
+execution of arbitrary code.  Some parts of links may be treated as
+shell specials.  Choosing of a proper function to invoke external
+application is a non-trivial task even for seasoned Emacs developers.
+Consult source code of ~browse-url-xdg-open~,
+~browse-url-default-macosx-browser~, or
+~browse-url-default-windows-browser~ for GNU/Linux,
+Mac\nbsp{}OS\nbsp{}X, or MS\nbsp{}Windows platforms accordingly.
 
-=M-x customize-variable org-link-mailto-program=
-
-The default function called is =browse-url=, which opens a mail
-composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
-Thus, if you want to ensure that mailto links use Gnus to open a
-message buffer, you could add the following to your =.emacs=:
+#+begin_comment
+Recurring source of pain is interaction of Emacs function with
+=xdg-open=, =kde-open5=, =gio open= utilities on Linux.  While
+~call-process~ with 0 as ~DESTINATION~ argument for
+~browse-url-generic~ was settled in 2004, ~browse-url-xdg-open~ was
+evolving to similar code in 2011.  Notice that application has no
+chance to notify Emacs about failure.
+
+Example of confusion that fortunately was not resulted in changing of
+code: [[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]] There was
+a lengthy thread "& and M-& to run programs asynchronously" in 2009
+with strange conclusion that it is a bug in Gnome utility:
+[[https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html]]
+
+~org-open-file~ and ~mailcap-view-mime~ use another approach to launch
+application (shell is required by mailcap RFC-1524).  A prompt to kill
+process may appear quitting from Emacs, some application might cause
+high CPU consumption by Emacs.  See
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824 and
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972 for details.
+
+Have this in mind if you decide to add more examples.
+#+end_comment
 
-#+begin_src elisp
-(setq mail-user-agent 'gnus-user-agent)
+When you are ready with a function launching your preferred handler
+for =mailto:= links, you should add it to ~browse-url-handlers~
+associations list for Emacs-28.1 and newer or to
+~browse-url-browser-function~ for earlier versions by customizing the
+suitable variable.
+
+If you are going to change handler just in Org mode in a way that does
+not affect rest of Emacs than you can adjust it through
+[[elisp:(customize-variable 'org-link-parameters)][=M-x customize-variable RET org-link-parameters RET=]], e.g. for
+Mac\nbsp{}OS\nbsp{}X link property may be following (on Linux to avoid
+silent failures add ~(process-connection-type nil)~ to ~let~ variables
+or use ~call-process~ with =0= as the =DESTINATION= argument):
+
+#+begin_src elisp :results none
+("mailto"
+ :follow (lambda (path)
+	   (let ((url (concat "mailto:" path)))
+	     ;; platform-specific choice of function
+	     (start-process (concat "open " url) nil
+			    "open" "-a" "Thunderbird" "--args" url))))
 #+end_src
 
+In earlier versions Org had ~org-link-mailto-program~ variable, but it
+was removed, so its customization does not work any more.  Update your
+init file if you noticed this variable.
+
 ** Can I use CamelCase links?
    :PROPERTIES:
    :CUSTOM_ID: CamelCase-links
-- 
2.25.1

Re: [PATCH] Fix FAQ entry about mailto links.

[Robert Goldman]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On 7 Feb 2022, at 10:59, Max Nikulin wrote:

> Robert,
>
> Thank you for pointing out that `org-link-mailto-program' should not 
> be recommended in FAQ any more.
>
> I prepared an alternative patch that recommends to customize Emacs 
> variables at first. I hope, an example is safer now, however I can not 
> test it on MacOS. Could you, please, review the patch, since I may 
> miss something important from your point of view?
>
> On 07/01/2022 18:03, Max Nikulin wrote:
>> On 07/01/2022 01:34, Robert Goldman wrote:
>>>
>>> +You can also change the function used to a different one.  For
>>> +example, the following function (on MacOS) opens =mailto:= links in
>>> +the =MailMate= program:
>
> I am unsure if MailMate is acceptable since it is a proprietary 
> application. Org is a part of *GNU* Emacs, so it may be better to 
> mention some free mail user agent.
>
>>> +#+begin_src elisp
>>> +("mailto" :follow
>>      ^
>> It seems, `org-link-set-parameters' is missed.
>
> I am sorry, I missed that you suggested to customize the 
> `org-link-parameters' variable, so function call is not necessary 
> here.

There are a couple of minor issues in the patch you sent (including a 
couple of grammatical errors), so attached is a revision.

I'm afraid there are now multiple patch files.

Please note that I have requested clarification at several places in the 
comment block.

Best,
R



[-- Attachment #2: 0001-Fix-FAQ-entry-about-mailto-links.patch --]
[-- Type: text/plain, Size: 1950 bytes --]

From b8158af7a839a751e6976cd95d18a5d5f199024a Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman" <rpgoldman@sift.net>
Date: Thu, 6 Jan 2022 12:27:59 -0600
Subject: [PATCH 1/4] Fix FAQ entry about mailto links.

The old entry referred to the variable =org-link-mailto-program= which
was removed from org-mode almost eight years ago!  See org-mode commit
b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb
---
 org-faq.org | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 4b34560c..cac8063e 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
 #+index: Link!Mailto
 
 You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+changing the entry for =mailto:= links in =org-link-parameters=:
 
-=M-x customize-variable org-link-mailto-program=
+=M-x customize-variable org-link-parameters=
 
 The default function called is =browse-url=, which opens a mail
 composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
+=browse-url= depends on the setting of the variable =mail-user-agent=.
 Thus, if you want to ensure that mailto links use Gnus to open a
 message buffer, you could add the following to your =.emacs=:
 
@@ -1941,6 +1941,18 @@ message buffer, you could add the following to your =.emacs=:
 (setq mail-user-agent 'gnus-user-agent)
 #+end_src
 
+You can also change the function used to a different one.  For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
+
+#+begin_src elisp
+("mailto" :follow
+      (lambda
+        (path)
+        (shell-command
+         (format "open -a MailMate 'mailto:%s'" path))))
+#+end_src
+
 ** Can I use CamelCase links?
    :PROPERTIES:
    :CUSTOM_ID: CamelCase-links
-- 
2.31.1


[-- Attachment #3: 0002-Revert-Fix-FAQ-entry-about-mailto-links.patch --]
[-- Type: text/plain, Size: 1837 bytes --]

From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman" <rpgoldman@sift.net>
Date: Thu, 10 Feb 2022 11:20:36 -0600
Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links."

This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a.
---
 org-faq.org | 18 +++---------------
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index cac8063e..4b34560c 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
 #+index: Link!Mailto
 
 You can customize the function org-mode uses to open mailto links by
-changing the entry for =mailto:= links in =org-link-parameters=:
+setting the variable =org-link-mailto-program=:
 
-=M-x customize-variable org-link-parameters=
+=M-x customize-variable org-link-mailto-program=
 
 The default function called is =browse-url=, which opens a mail
 composition buffer within Emacs. The type of buffer opened by
-=browse-url= depends on the setting of the variable =mail-user-agent=.
+browse-url depends on the setting of the variable =mail-user-agent=.
 Thus, if you want to ensure that mailto links use Gnus to open a
 message buffer, you could add the following to your =.emacs=:
 
@@ -1941,18 +1941,6 @@ message buffer, you could add the following to your =.emacs=:
 (setq mail-user-agent 'gnus-user-agent)
 #+end_src
 
-You can also change the function used to a different one.  For
-example, the following function (on MacOS) opens =mailto:= links in
-the =MailMate= program:
-
-#+begin_src elisp
-("mailto" :follow
-      (lambda
-        (path)
-        (shell-command
-         (format "open -a MailMate 'mailto:%s'" path))))
-#+end_src
-
 ** Can I use CamelCase links?
    :PROPERTIES:
    :CUSTOM_ID: CamelCase-links
-- 
2.31.1


[-- Attachment #4: 0003-From-Max-Nikulin.patch --]
[-- Type: text/plain, Size: 5314 bytes --]

From 2fcf6bd07aa3e09cd11328e9e57cf3915c08a667 Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman" <rpgoldman@sift.net>
Date: Thu, 10 Feb 2022 11:21:11 -0600
Subject: [PATCH 3/4] From Max Nikulin.

---
 org-faq.org | 87 ++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 76 insertions(+), 11 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 4b34560c..b6bde3ca 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1926,21 +1926,86 @@ For example:
 
 #+index: Link!Mailto
 
-You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+Org calls ~browse-url~ function for =mailto:= links, so it should obey
+your Emacs configuration.  If something goes wrong then
+[[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good starting point.
+
+By default mail is composed in an Emacs buffer.  If you prefer some
+external application instead than set ~browse-url-mailto-function~ to
+nil, e.g. using
+[[elisp:(customize-variable 'browse-url-mailto-function)][=M-x customize-variable RET browse-url-mailto-function RET=]]
+and =mailto:= links will be opened accordingly to
+~browse-url~browser-function~ value.
+
+If you intention is to compose messages in Emacs then consult
+[[info:emacs#Mail Methods][info "(emacs) Mail Methods"]].  Check that ~browse-url-mailto-function~
+has its default value ~browse-url-mail~.  Emacs has several mail
+packages, so next step may be
+[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]] to set the variable
+to e.g. =gnus-user-agent=.
+
+If you prefer an external application other than configured in desktop
+environment then you should write a custom URL handler function.  Be
+careful, try to avoid shell (e.g. ~shell-command~ function) since it
+is easy to mess up with escaping of the URL argument and thus to allow
+execution of arbitrary code.  Some parts of links may be treated as
+shell specials.  Choosing of a proper function to invoke external
+application is a non-trivial task even for seasoned Emacs developers.
+Consult source code of ~browse-url-xdg-open~,
+~browse-url-default-macosx-browser~, or
+~browse-url-default-windows-browser~ for GNU/Linux,
+Mac\nbsp{}OS\nbsp{}X, or MS\nbsp{}Windows platforms accordingly.
 
-=M-x customize-variable org-link-mailto-program=
-
-The default function called is =browse-url=, which opens a mail
-composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
-Thus, if you want to ensure that mailto links use Gnus to open a
-message buffer, you could add the following to your =.emacs=:
+#+begin_comment
+Recurring source of pain is interaction of Emacs function with
+=xdg-open=, =kde-open5=, =gio open= utilities on Linux.  While
+~call-process~ with 0 as ~DESTINATION~ argument for
+~browse-url-generic~ was settled in 2004, ~browse-url-xdg-open~ was
+evolving to similar code in 2011.  Notice that application has no
+chance to notify Emacs about failure.
+
+Example of confusion that fortunately was not resulted in changing of
+code: [[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]] There was
+a lengthy thread "& and M-& to run programs asynchronously" in 2009
+with strange conclusion that it is a bug in Gnome utility:
+[[https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html]]
+
+~org-open-file~ and ~mailcap-view-mime~ use another approach to launch
+application (shell is required by mailcap RFC-1524).  A prompt to kill
+process may appear quitting from Emacs, some application might cause
+high CPU consumption by Emacs.  See
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824 and
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972 for details.
+
+Have this in mind if you decide to add more examples.
+#+end_comment
 
-#+begin_src elisp
-(setq mail-user-agent 'gnus-user-agent)
+When you are ready with a function launching your preferred handler
+for =mailto:= links, you should add it to ~browse-url-handlers~
+associations list for Emacs-28.1 and newer or to
+~browse-url-browser-function~ for earlier versions by customizing the
+suitable variable.
+
+If you are going to change handler just in Org mode in a way that does
+not affect rest of Emacs than you can adjust it through
+[[elisp:(customize-variable 'org-link-parameters)][=M-x customize-variable RET org-link-parameters RET=]], e.g. for
+Mac\nbsp{}OS\nbsp{}X link property may be following (on Linux to avoid
+silent failures add ~(process-connection-type nil)~ to ~let~ variables
+or use ~call-process~ with =0= as the =DESTINATION= argument):
+
+#+begin_src elisp :results none
+("mailto"
+ :follow (lambda (path)
+	   (let ((url (concat "mailto:" path)))
+	     ;; platform-specific choice of function
+	     (start-process (concat "open " url) nil
+			    "open" "-a" "Thunderbird" "--args" url))))
 #+end_src
 
+In earlier versions Org had ~org-link-mailto-program~ variable, but it
+was removed, so its customization does not work any more.  Update your
+init file if you noticed this variable.
+
 ** Can I use CamelCase links?
    :PROPERTIES:
    :CUSTOM_ID: CamelCase-links
-- 
2.31.1


[-- Attachment #5: 0004-Further-edits-to-Max-Nikulin-s-patch.patch --]
[-- Type: text/plain, Size: 6362 bytes --]

From 9d415c3d55c3f0817598b7d746d96ae9f602623c Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman" <rpgoldman@sift.net>
Date: Thu, 10 Feb 2022 11:39:53 -0600
Subject: [PATCH 4/4] Further edits to Max Nikulin's patch.

---
 org-faq.org | 84 +++++++++++++++++++++++++++++++++++------------------
 1 file changed, 55 insertions(+), 29 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index b6bde3ca..1819326c 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1926,58 +1926,84 @@ For example:
 
 #+index: Link!Mailto
 
-Org calls ~browse-url~ function for =mailto:= links, so it should obey
+Org calls the ~browse-url~ function for =mailto:= links, so it should obey
 your Emacs configuration.  If something goes wrong then
 [[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good starting point.
 
 By default mail is composed in an Emacs buffer.  If you prefer some
-external application instead than set ~browse-url-mailto-function~ to
-nil, e.g. using
+external application instead then set ~browse-url-mailto-function~ to
+=nil=, e.g. using
 [[elisp:(customize-variable 'browse-url-mailto-function)][=M-x customize-variable RET browse-url-mailto-function RET=]]
-and =mailto:= links will be opened accordingly to
-~browse-url~browser-function~ value.
+and =mailto:= links will be opened according to the value of
+~browse-url~browser-function~.
 
-If you intention is to compose messages in Emacs then consult
+If you wish to compose messages in Emacs then consult
 [[info:emacs#Mail Methods][info "(emacs) Mail Methods"]].  Check that ~browse-url-mailto-function~
 has its default value ~browse-url-mail~.  Emacs has several mail
-packages, so next step may be
-[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]] to set the variable
-to e.g. =gnus-user-agent=.
-
-If you prefer an external application other than configured in desktop
-environment then you should write a custom URL handler function.  Be
-careful, try to avoid shell (e.g. ~shell-command~ function) since it
-is easy to mess up with escaping of the URL argument and thus to allow
-execution of arbitrary code.  Some parts of links may be treated as
-shell specials.  Choosing of a proper function to invoke external
+packages, so the next step may be to configure that variable to, e.g.,
+ =gnus-user-agent= using
+[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]] .
+
+If you prefer an external application that is /not/ the one configured
+in your desktop environment,
+then you should write a custom URL handler function.  Be
+careful, try to avoid using the shell (e.g. ~shell-command~ function) since it
+is easy to mess up the escaping of the URL argument and allow
+execution of arbitrary code: some parts of links may be treated as
+shell specials.  Choosing a proper function to invoke an external
 application is a non-trivial task even for seasoned Emacs developers.
-Consult source code of ~browse-url-xdg-open~,
+For examples, consult the source code of ~browse-url-xdg-open~,
 ~browse-url-default-macosx-browser~, or
 ~browse-url-default-windows-browser~ for GNU/Linux,
 Mac\nbsp{}OS\nbsp{}X, or MS\nbsp{}Windows platforms accordingly.
 
 #+begin_comment
-Recurring source of pain is interaction of Emacs function with
-=xdg-open=, =kde-open5=, =gio open= utilities on Linux.  While
+A recurring source of pain for Emacs users is the interaction
+of Emacs functions with the
+=xdg-open=, =kde-open5=, and =gio open= utilities on Linux.  While
 ~call-process~ with 0 as ~DESTINATION~ argument for
 ~browse-url-generic~ was settled in 2004, ~browse-url-xdg-open~ was
-evolving to similar code in 2011.  Notice that application has no
-chance to notify Emacs about failure.
-
-Example of confusion that fortunately was not resulted in changing of
-code: [[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]] There was
+evolving to similar code in 2011.  Notice that the application has no
+chance to notify Emacs if it fails.
+
+**side comment:** the above paragraph is hard to understand. Would it be
+possible to add pointers to the discussion of these issues? Also what
+is meant by "~browse-url-xdg-open~ was evolving to similar code in
+2011."  Finally, it's not /generally/ true that subprocess
+applications can't inform Emacs of failures.  I believe that what is
+meant here is something more like "Notice that applications invoked
+through =browse-url-<foo>= have no way to notify Emacs if they fail."
+This makes sense, because browsers don't exit with a bad exit status
+if they fail to open a URL as expected. -- rpg
+
+**End of side comment**
+
+Example of this confusion:
+[[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]] 
+There was
 a lengthy thread "& and M-& to run programs asynchronously" in 2009
-with strange conclusion that it is a bug in Gnome utility:
+which reached the strange conclusion that it is a bug in Gnome utility:
 [[https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html]]
 
+**Side comment:** The above paragraph is also difficult to parse.
+Confusion about what?  Lack of error report?  What does it mean "has
+not resulted in changing of code"? I have cut that.  Also, which Gnome
+utility do you mean here? Or did you just mean "a bug in the Gnome
+desktop"?  **End**
+
 ~org-open-file~ and ~mailcap-view-mime~ use another approach to launch
-application (shell is required by mailcap RFC-1524).  A prompt to kill
-process may appear quitting from Emacs, some application might cause
-high CPU consumption by Emacs.  See
+applications (shell is required by mailcap RFC-1524).  This approach
+can lead to user confusion such as:
+A prompt to kill
+such applications' process may appear to users to be a prompt to quit
+Emacs;
+some applications might cause high CPU consumption by Emacs.  See
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824 and
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972 for details.
 
-Have this in mind if you decide to add more examples.
+**Please review the above edits.**
+
+Keep these considerations in mind if you decide to add more examples.
 #+end_comment
 
 When you are ready with a function launching your preferred handler
-- 
2.31.1

[PATCH v3] Fix FAQ entry about mailto links.

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 4944 bytes --]

On 11/02/2022 00:42, Robert Goldman wrote:
> 
> There are a couple of minor issues in the patch you sent (including a 
> couple of grammatical errors), so attached is a revision.

Great. Thank you, Robert, it exact reason why I asked for a review.

I am sending the updated patch and a diff to your edits to highlight my 
latest changes.

> From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001
> From: "Robert P. Goldman" <rpgoldman@sift.net>
> Date: Thu, 10 Feb 2022 11:20:36 -0600
> Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links."
> 
> This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a.

Would you like to have you original version in git history? For me it is 
not a problem to make my patch updating yours one without reverting the 
original commit (create another branch, cherry-pick commits, resolve 
conflict to the latest state).  Otherwise you can avoid unnecessary 
commits in your local repository by either applying my patch to a new 
branch or using "git rebase -i master" to drop unnecessary commits.

> +If you prefer an external application that is /not/ the one configured
> +in your desktop environment,

What is bothering me a bit is the entry title "Org-mode is not opening 
mailto links in my *default* mail client". The updated variant mostly 
discusses changing of defaults.

> +**side comment:** the above paragraph is hard to understand. Would it be
> +possible to add pointers to the discussion of these issues?

I do not follow Emacs development. The source is git commit history and 
commit messages rarely have links to discussion or references to bug 
tracker.

> Also what
> +is meant by "~browse-url-xdg-open~ was evolving to similar code in
> +2011."  Finally, it's not /generally/ true that subprocess
> +applications can't inform Emacs of failures.

The reality is that failures of xdg-open are confusingly quiet. Often 
nil is specified as the buffer for standard error (application may spam 
with warnings and failed assert). For `start-process' or `make-process' 
it is necessary to create a handler that displays message on process 
failure. `call-process' with 0 as DESTINATION signals error only if it 
can not find the executable otherwise only desktop environment may 
notify user about an error.

> I believe that what is
> +meant here is something more like "Notice that applications invoked
> +through =browse-url-<foo>= have no way to notify Emacs if they fail."
> +This makes sense, because browsers don't exit with a bad exit status
> +if they fail to open a URL as expected. -- rpg

It is another sort of errors and browser may show an error page. Notice 
that executable may just send a command to an already running process 
and to exit almost instantly.

> +which reached the strange conclusion that it is a bug in Gnome utility:

I would not say "reached". The statement appeared in the middle of 
discussion and the problem was not fixed that time.

> +**Side comment:** The above paragraph is also difficult to parse.
> +Confusion about what?  Lack of error report?  What does it mean "has
> +not resulted in changing of code"? I have cut that.  Also, which Gnome
> +utility do you mean here? Or did you just mean "a bug in the Gnome
> +desktop"?  **End**

Confusion whether nohup wrapper is necessary. It was removed a bit 
earlier by a participant of the discussion of the bug 9779 and I believe
that the change was correct since dropping of nohup was accompanied by 
other changes. I do not remember what was the name of the gnome utility 
that time, maybe gnome-open, currently it is "gio open" but for most of 
people it is anyway hidden behind xdg-open and namely xdg-open usually 
becomes the target to blame.

 > On 7 Feb 2022, at 10:59, Max Nikulin wrote:

>> +#+begin_comment
>> +Recurring source of pain is interaction of Emacs function with

Notice that comment is dropped during export, it is visible only to 
contributors who will decide to update the entry.  I am unsure where 
such note should be placed: separate worg page, emacswiki site, etc. 
Even Org has several files with quite similar problems with launching of 
viewers.

>> +[[elisp:(customize-variable 'org-link-parameters)][=M-x customize-variable RET org-link-parameters RET=]], e.g. for
Actually I am unsure if customization of `org-link-parameters' should be 
recommended. The interface contains a lot of entries actually added by 
org packages. Maybe it is better to suggest

   (with-eval-after-load 'ol
     (org-link-set-parameters
     ;; ...

>> +#+begin_src elisp :results none
>> +("mailto"
>> + :follow (lambda (path)
>> +	   (let ((url (concat "mailto:" path)))
>> +	     ;; platform-specific choice of function
>> +	     (start-process (concat "open " url) nil
>> +			    "open" "-a" "Thunderbird" "--args" url))))
                                                        ^^^^^^^

Notice this addition, I can not test if it really works.

>>  #+end_src

[-- Attachment #2: 0001-FAQ-Update-suggestion-for-mailto-link-handlers.patch --]
[-- Type: text/x-patch, Size: 6771 bytes --]

From 8eeb353a45521ab34cced37971e4455f870671c9 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Mon, 7 Feb 2022 23:40:37 +0700
Subject: [PATCH] FAQ: Update suggestion for mailto: link handlers

org-faq.org (mailto-links): Mention `org-link-mailto-program' as removed
variable, recommend customization of `browse-url-mailto-function' or
`org-link-parameters' instead.

This change is prepared in cooperation with Robert Goldman <rpgoldman@sift.net>,
see https://list.orgmode.org/FEAD92A6-87DE-4CFF-8459-E3D012DD3F52@sift.net
for the initial suggestion.
---
 org-faq.org | 104 ++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 93 insertions(+), 11 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 4b34560c..323fba6b 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1926,21 +1926,103 @@ For example:
 
 #+index: Link!Mailto
 
-You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+Org calls the ~browse-url~ function for =mailto:= links, so it should obey
+your Emacs configuration.  If something goes wrong then
+[[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good starting point.
+
+By default mail is composed in an Emacs buffer.  If you prefer some
+external application instead then set ~browse-url-mailto-function~ to
+~nil~, e.g. using
+[[elisp:(customize-variable 'browse-url-mailto-function)][=M-x customize-variable RET browse-url-mailto-function RET=]]
+and =mailto:= links will be opened according to the value of
+~browse-url~browser-function~.
+
+If you wish to compose messages in Emacs then consult
+[[info:emacs#Mail Methods][info "(emacs) Mail Methods"]].  Check that ~browse-url-mailto-function~
+has its default value ~browse-url-mail~.  Emacs has several mail
+packages and the active one is determined by the ~mail-user-agent~ variable,
+so the next step may be to configure it to, e.g., =gnus-user-agent= using
+[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]].
+
+If you prefer an external application that is /not/ the one configured
+in your desktop environment,
+then you should write a custom URL handler function.  Be
+careful, try to avoid using the shell (e.g. ~shell-command~ function) since it
+is easy to mess up the escaping of the URL argument and allow
+execution of arbitrary code: some parts of links may be treated as
+shell specials.  Choosing a proper function to invoke an external
+application is a non-trivial task even for seasoned Emacs developers.
+When possible use an option like double dash =--= before URLs that forces
+interpreting following as arguments even when a string resembles some option
+due to a leading dash.
+For examples, consult the source code of ~browse-url-xdg-open~,
+~browse-url-default-macosx-browser~, or
+~browse-url-default-windows-browser~ for GNU/Linux,
+Mac\nbsp{}OS\nbsp{}X, or MS\nbsp{}Windows platforms accordingly.
 
-=M-x customize-variable org-link-mailto-program=
-
-The default function called is =browse-url=, which opens a mail
-composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
-Thus, if you want to ensure that mailto links use Gnus to open a
-message buffer, you could add the following to your =.emacs=:
+#+begin_comment
+A recurring source of pain for users is the interaction
+of Emacs functions with the
+=xdg-open=, =kde-open5=, and =gio open= utilities on Linux.  While
+~call-process~ with 0 as ~DESTINATION~ argument for
+~browse-url-generic~ was settled in 2004, the introduced later
+~browse-url-xdg-open~ function was evolving to similar code in 2011.
+See commit history for earlier steps.  Notice that with the ~call-process~
+approach the application has no chance to notify Emacs if it fails.
+
+Example of confusion with techniques to launch applications is comment
+[[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]]
+that falsely points out to missed =nohup= despite of usage the ~call-process~ function.
+Its choice is not intuitive since normally ~call-process~
+waits till process completion.  However with 0 (not ~nil~!) argument
+it creates a completely detached process.
+It is asynchronous ~start-process~
+and ~make~process~ functions that create a pty by default and so kill
+children by =SIGHUP= signal when the main process exits after fork.
+There was
+a lengthy thread "& and M-& to run programs asynchronously" in 2009
+with a comment containing a strange conclusion that immediate exit is a bug
+in the Gnome CLI utility launching MIME handler:
+[[https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html]].
+
+~org-open-file~ and ~mailcap-view-mime~ functions create asynchronous processes to launch
+applications (shell is required by mailcap RFC-1524 so the code does not follow the recommendation given above),
+but they use pipe processes instead of default pty ones.
+This approach has downsides as well.  In some cases application can not run longer
+than Emacs (a prompt to confirm its termination may appear on attempt to quit from Emacs).
+Some applications might cause high CPU consumption by Emacs.  See
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824 and
+https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972 for details.
+
+Keep these considerations in mind if you decide to add more examples.
+#+end_comment
 
-#+begin_src elisp
-(setq mail-user-agent 'gnus-user-agent)
+When you are ready with a function launching your preferred handler
+for =mailto:= links, you should add it to ~browse-url-handlers~
+associations list for Emacs-28.1 and newer or to
+~browse-url-browser-function~ for earlier versions by customizing the
+suitable variable.
+
+If you are going to change handler just in Org mode in a way that does
+not affect rest of Emacs than you can adjust it through
+[[elisp:(customize-variable 'org-link-parameters)][=M-x customize-variable RET org-link-parameters RET=]], e.g. for
+Mac\nbsp{}OS\nbsp{}X link property may be following (on Linux to avoid
+silent failures add ~(process-connection-type nil)~ to ~let~ variables
+or use ~call-process~ with =0= as the =DESTINATION= argument):
+
+#+begin_src elisp :results none
+("mailto"
+ :follow (lambda (path)
+	   (let ((url (concat "mailto:" path)))
+	     ;; platform-specific choice of function
+	     (start-process (concat "open " url) nil
+			    "open" "-a" "Thunderbird" "--args" url))))
 #+end_src
 
+In earlier versions Org had ~org-link-mailto-program~ variable, but it
+was removed, so its customization does not work any more.  Update your
+init file if you noticed this variable.
+
 ** Can I use CamelCase links?
    :PROPERTIES:
    :CUSTOM_ID: CamelCase-links
-- 
2.25.1


[-- Attachment #3: faq-mailto-changes-since-2022-02-11-goldman.diff --]
[-- Type: text/x-patch, Size: 6285 bytes --]

commit e151f6d800e216ba2586b309f777efed81197572
Author: Max Nikulin <manikulin@gmail.com>
Date:   Mon Feb 14 19:21:54 2022 +0700

    [DRAFT] Diff to Robert P. Goldman's revision
    
    This is not a real patch. The intention is to show
    changes made in response to the review.

diff --git a/org-faq.org b/org-faq.org
index 1819326c..323fba6b 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1932,7 +1932,7 @@ your Emacs configuration.  If something goes wrong then
 
 By default mail is composed in an Emacs buffer.  If you prefer some
 external application instead then set ~browse-url-mailto-function~ to
-=nil=, e.g. using
+~nil~, e.g. using
 [[elisp:(customize-variable 'browse-url-mailto-function)][=M-x customize-variable RET browse-url-mailto-function RET=]]
 and =mailto:= links will be opened according to the value of
 ~browse-url~browser-function~.
@@ -1940,9 +1940,9 @@ and =mailto:= links will be opened according to the value of
 If you wish to compose messages in Emacs then consult
 [[info:emacs#Mail Methods][info "(emacs) Mail Methods"]].  Check that ~browse-url-mailto-function~
 has its default value ~browse-url-mail~.  Emacs has several mail
-packages, so the next step may be to configure that variable to, e.g.,
- =gnus-user-agent= using
-[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]] .
+packages and the active one is determined by the ~mail-user-agent~ variable,
+so the next step may be to configure it to, e.g., =gnus-user-agent= using
+[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]].
 
 If you prefer an external application that is /not/ the one configured
 in your desktop environment,
@@ -1952,57 +1952,48 @@ is easy to mess up the escaping of the URL argument and allow
 execution of arbitrary code: some parts of links may be treated as
 shell specials.  Choosing a proper function to invoke an external
 application is a non-trivial task even for seasoned Emacs developers.
+When possible use an option like double dash =--= before URLs that forces
+interpreting following as arguments even when a string resembles some option
+due to a leading dash.
 For examples, consult the source code of ~browse-url-xdg-open~,
 ~browse-url-default-macosx-browser~, or
 ~browse-url-default-windows-browser~ for GNU/Linux,
 Mac\nbsp{}OS\nbsp{}X, or MS\nbsp{}Windows platforms accordingly.
 
 #+begin_comment
-A recurring source of pain for Emacs users is the interaction
+A recurring source of pain for users is the interaction
 of Emacs functions with the
 =xdg-open=, =kde-open5=, and =gio open= utilities on Linux.  While
 ~call-process~ with 0 as ~DESTINATION~ argument for
-~browse-url-generic~ was settled in 2004, ~browse-url-xdg-open~ was
-evolving to similar code in 2011.  Notice that the application has no
-chance to notify Emacs if it fails.
-
-**side comment:** the above paragraph is hard to understand. Would it be
-possible to add pointers to the discussion of these issues? Also what
-is meant by "~browse-url-xdg-open~ was evolving to similar code in
-2011."  Finally, it's not /generally/ true that subprocess
-applications can't inform Emacs of failures.  I believe that what is
-meant here is something more like "Notice that applications invoked
-through =browse-url-<foo>= have no way to notify Emacs if they fail."
-This makes sense, because browsers don't exit with a bad exit status
-if they fail to open a URL as expected. -- rpg
-
-**End of side comment**
-
-Example of this confusion:
-[[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]] 
+~browse-url-generic~ was settled in 2004, the introduced later
+~browse-url-xdg-open~ function was evolving to similar code in 2011.
+See commit history for earlier steps.  Notice that with the ~call-process~
+approach the application has no chance to notify Emacs if it fails.
+
+Example of confusion with techniques to launch applications is comment
+[[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]]
+that falsely points out to missed =nohup= despite of usage the ~call-process~ function.
+Its choice is not intuitive since normally ~call-process~
+waits till process completion.  However with 0 (not ~nil~!) argument
+it creates a completely detached process.
+It is asynchronous ~start-process~
+and ~make~process~ functions that create a pty by default and so kill
+children by =SIGHUP= signal when the main process exits after fork.
 There was
 a lengthy thread "& and M-& to run programs asynchronously" in 2009
-which reached the strange conclusion that it is a bug in Gnome utility:
-[[https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html]]
-
-**Side comment:** The above paragraph is also difficult to parse.
-Confusion about what?  Lack of error report?  What does it mean "has
-not resulted in changing of code"? I have cut that.  Also, which Gnome
-utility do you mean here? Or did you just mean "a bug in the Gnome
-desktop"?  **End**
-
-~org-open-file~ and ~mailcap-view-mime~ use another approach to launch
-applications (shell is required by mailcap RFC-1524).  This approach
-can lead to user confusion such as:
-A prompt to kill
-such applications' process may appear to users to be a prompt to quit
-Emacs;
-some applications might cause high CPU consumption by Emacs.  See
+with a comment containing a strange conclusion that immediate exit is a bug
+in the Gnome CLI utility launching MIME handler:
+[[https://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html]].
+
+~org-open-file~ and ~mailcap-view-mime~ functions create asynchronous processes to launch
+applications (shell is required by mailcap RFC-1524 so the code does not follow the recommendation given above),
+but they use pipe processes instead of default pty ones.
+This approach has downsides as well.  In some cases application can not run longer
+than Emacs (a prompt to confirm its termination may appear on attempt to quit from Emacs).
+Some applications might cause high CPU consumption by Emacs.  See
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824 and
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972 for details.
 
-**Please review the above edits.**
-
 Keep these considerations in mind if you decide to add more examples.
 #+end_comment
 

Re: [PATCH v3] Fix FAQ entry about mailto links.

[Robert Goldman]

On 14 Feb 2022, at 7:22, Max Nikulin wrote:

> On 11/02/2022 00:42, Robert Goldman wrote:
>>
>> There are a couple of minor issues in the patch you sent (including a 
>> couple of grammatical errors), so attached is a revision.
>
> Great. Thank you, Robert, it exact reason why I asked for a review.
>
> I am sending the updated patch and a diff to your edits to highlight 
> my latest changes.

Hello, Max --

Some responses below, then I think merging would be fine. I am losing my 
ability and energy to process these patch files, honestly.

>
>> From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 
>> 2001
>> From: "Robert P. Goldman" <rpgoldman@sift.net>
>> Date: Thu, 10 Feb 2022 11:20:36 -0600
>> Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links."
>>
>> This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a.
>
> Would you like to have you original version in git history? For me it 
> is not a problem to make my patch updating yours one without reverting 
> the original commit (create another branch, cherry-pick commits, 
> resolve conflict to the latest state).  Otherwise you can avoid 
> unnecessary commits in your local repository by either applying my 
> patch to a new branch or using "git rebase -i master" to drop 
> unnecessary commits.

I don't need to be credited; it would be fine to just merge in whatever 
way is convenient.
>
>> +If you prefer an external application that is /not/ the one 
>> configured
>> +in your desktop environment,
>
> What is bothering me a bit is the entry title "Org-mode is not opening 
> mailto links in my *default* mail client". The updated variant mostly 
> discusses changing of defaults.

The whole thing addresses how to open mailto links in the default mail 
client. It's not our fault that figuring out how org-mode dispatches 
these links and then what goes on inside browse-url is so complicated!

>> +**side comment:** the above paragraph is hard to understand. Would 
>> it be
>> +possible to add pointers to the discussion of these issues?
>
> I do not follow Emacs development. The source is git commit history 
> and commit messages rarely have links to discussion or references to 
> bug tracker.

To be honest, I'm not sure what value this whole comment section has.  
Given that, I'm ok with whatever you want to do: leave it as it, try to 
fix it, or just remove it altogether. I actually think that removing it 
might be best. It's confusing, and will eventually become out-of-date, 
and who will update it?

I'll leave it to you to choose.

Best,
R

Re: [PATCH v3] Fix FAQ entry about mailto links.

[Max Nikulin]

On 16/02/2022 08:29, Robert Goldman wrote:
> On 14 Feb 2022, at 7:22, Max Nikulin wrote:
>> On 11/02/2022 00:42, Robert Goldman wrote:
>>
>> I am sending the updated patch and a diff to your edits to highlight 
>> my latest changes.
> 
> Some responses below, then I think merging would be fine. I am losing my 
> ability and energy to process these patch files, honestly.

One patch was for clean master HEAD state, another file was diff in 
comparison to your variant. The latter could be applied on the top of 
your patches or one could just read it to see changes.

> To be honest, I'm not sure what value this whole comment section has. 
> Given that, I'm ok with whatever you want to do: leave it as it, try to 
> fix it, or just remove it altogether. I actually think that removing it 
> might be best. It's confusing, and will eventually become out-of-date, 
> and who will update it?

I pushed the patch without comment block. I decided to suggest 
`org-link-set-parameters' instead of customization of 
`org-link-parameters'. See updated variant at 
https://orgmode.org/worg/org-faq.html#mailto-links.

Robert, thank you for suggesting corrections and for reviewing my patches.

P.S. I was surprised that Apple does not provide online version of man 
pages for MacOS utilities.

Re: [PATCH v3] Fix FAQ entry about mailto links.

[Max Nikulin]

On 25/02/2022 19:20, Max Nikulin wrote:
> 
> I pushed the patch without comment block. I decided to suggest 
> `org-link-set-parameters' instead of customization of 
> `org-link-parameters'. See updated variant at 
> https://orgmode.org/worg/org-faq.html#mailto-links.

This patch should be removed from the list of pending ones on 
https://updates.orgmode.org/ so

Applied

Re: [PATCH] Fix FAQ entry about mailto links.

[Max Nikulin]

Sorry for the noise. Another attempt to remove the record from 
https://updates.orgmode.org

Canceled.

Another variant based on 
https://list.orgmode.org/9437ade2-af18-f97e-8790-a2df27c9017c@gmail.com 
has been committed.

On 07/01/2022 01:34, Robert Goldman wrote:
> 
> The old entry referred to the variable =org-link-mailto-program= which
> was removed from org-mode almost eight years ago!  See org-mode commit
> b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb
> ---
>   org-faq.org | 18 +++++++++++++++---
>   1 file changed, 15 insertions(+), 3 deletions(-)