From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id KMxdEuhTBWIy/QAAgWs5BA (envelope-from ) for ; Thu, 10 Feb 2022 19:05:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id ICz/DuhTBWIAiAAAauVa8A (envelope-from ) for ; Thu, 10 Feb 2022 19:05:28 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0A20037139 for ; Thu, 10 Feb 2022 19:05:26 +0100 (CET) Received: from localhost ([::1]:58084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nIDor-0008Oq-70 for larch@yhetil.org; Thu, 10 Feb 2022 13:05:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIDX1-0002Sa-6N for emacs-orgmode@gnu.org; Thu, 10 Feb 2022 12:46:59 -0500 Received: from mail.sift.net ([50.249.120.161]:54697) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIDSm-0008NX-Hk for emacs-orgmode@gnu.org; Thu, 10 Feb 2022 12:42:39 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.sift.net (Postfix) with ESMTP id BAD678158BDE; Thu, 10 Feb 2022 11:42:34 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sift.net; h= content-transfer-encoding:content-type:content-type:mime-version :references:in-reply-to:message-id:x-mailer:date:date:subject :subject:from:from:received:received; s=sift-net; t=1644514952; x=1645378953; bh=j9SmsXhoNyjGg8lEavfatyzjnyRqvwqUuBzNX41Tuao=; b= rt3QL4nG2/02mK7YOPgYDfX40HCu7dRoF+X7dcbKaK2QUHv9MbB0wybZEARreRZ4 ddrfqfke8Ea3ZbyvWFhesNV53KmXyyj7JAo7AwThDP1snEkpc1l0q3cxv8zHlFGZ ECg2q+xqW8HutS0SaDTPUDzcYSHeu8JuhGpOJNoorJjgSp5kmRi32S2+9GhoLRBW sHwqo3cJFXSnZOd3D2cdQRHa8FtjsVeR9+PdCii8cY0vCf8jv+Y7639H2s3YGJP/ A+/7F/hTy5bhUng4VLxqqdv5ft8q0aFSpEmd9vyiXSFv2InlK8q1hU8cd3C3P+fK QWBNjyo3mBx/PARMTuNHww== X-Virus-Scanned: Debian amavisd-new at sift.net Received: from mail.sift.net ([127.0.0.1]) by localhost (mail.sift.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O0NO8r91QQvp; Thu, 10 Feb 2022 11:42:32 -0600 (CST) Received: from [192.168.86.28] (162-219-230-90.fttp.usinternet.com [162.219.230.90]) (Authenticated sender: rpg) by mail.sift.net (Postfix) with ESMTPSA id AC8548151305; Thu, 10 Feb 2022 11:42:32 -0600 (CST) From: "Robert Goldman" To: "Max Nikulin" Subject: Re: [PATCH] Fix FAQ entry about mailto links. Date: Thu, 10 Feb 2022 11:42:24 -0600 X-Mailer: MailMate (1.13.2r5673) Message-ID: <11DC93C5-2600-4B6B-B7E0-B200AB274C35@sift.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_=" Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=50.249.120.161; envelope-from=rpgoldman@sift.net; helo=mail.sift.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1644516326; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=XrIUOLcBtxHSYmAr0AUfezLJ+u68pus49RWU9VesJ+8=; b=gxQ56DSz7ReqkCgr0x1XFM7aj5BOGlrVwhl1qCCy40ws7mP/GEdMbssZX5yuOsCAn9p0op knjL6hE10f19ELz1bXHnkvZEhTlnX9y1JDSs72xOnzpy2V/xmaXh2LEM9np7kedh3BhyXi Hd9+8b4YEaQk/PfmgGynpeNgvMKfNFNaY4KTChF6uVPpv+q4p1LanCqGYRdTRe8RxLXh6w 05ew8FzPfCwofy7ouKD5a0VCUQAzFBZMbgOLxJ5WWC0mVmkX+r9aeMKhXQTHrsClrBH6tM s01+gxnnWtPEWb4EyH5KKYv8fVmJI1BW7scToj4oMnlVYOpsFoiWFPUFNV59IQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1644516326; a=rsa-sha256; cv=none; b=ubKfZhLOwAt10zoVB/NtxR/p0mSNlyI2jA0kaTRJHYd8eDlmGcwXNi6iCAkknP7uoK2dpS L0EEvyj6pjCxu00y/EllwQ2RZKVIcyu6YQv1pXJKlDBHkFAJI4p6Ugl+RSQo7lKAwYn1Xm 0ZrDXO5TmjRQJ5Y4ugMjT+i/DGOhrQcJ5O/5WeoHStx+Co5h8YHgWCcNRogmaPuUG19AFQ 3edcFLL3gsy748mGJe5VUq7bAy/UM+0/+LsE790NJwAvRnTLLYFq4fHIUYpa8JHBry53Op WxI0Dzb1oc0znxcvosrTtgDPuum/5vlwiFSVuocYEmgmc6zAnv+Iuaf0DSfP2g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=sift.net header.s=sift-net header.b=rt3QL4nG; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -8.93 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=sift.net header.s=sift-net header.b=rt3QL4nG; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 0A20037139 X-Spam-Score: -8.93 X-Migadu-Scanner: scn0.migadu.com X-TUID: 7mNlnHXL/J1G --=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 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 --=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_= Content-Disposition: attachment; filename=0001-Fix-FAQ-entry-about-mailto-links.patch Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =46rom b8158af7a839a751e6976cd95d18a5d5f199024a Mon Sep 17 00:00:00 2001 From: "Robert P. Goldman" 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 =3Dorg-link-mailto-program=3D whic= h 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 =3Dorg-link-mailto-program=3D: +changing the entry for =3Dmailto:=3D links in =3Dorg-link-parameters=3D:= = -=3DM-x customize-variable org-link-mailto-program=3D +=3DM-x customize-variable org-link-parameters=3D = The default function called is =3Dbrowse-url=3D, which opens a mail composition buffer within Emacs. The type of buffer opened by -browse-url depends on the setting of the variable =3Dmail-user-agent=3D.= +=3Dbrowse-url=3D depends on the setting of the variable =3Dmail-user-age= nt=3D. Thus, if you want to ensure that mailto links use Gnus to open a message buffer, you could add the following to your =3D.emacs=3D: = @@ -1941,6 +1941,18 @@ message buffer, you could add the following to you= r =3D.emacs=3D: (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 =3Dmailto:=3D links in +the =3DMailMate=3D 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 --=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_= Content-Disposition: attachment; filename=0002-Revert-Fix-FAQ-entry-about-mailto-links.patch Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =46rom e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001 From: "Robert P. Goldman" 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 =3Dmailto:=3D links in =3Dorg-link-parameters=3D:= +setting the variable =3Dorg-link-mailto-program=3D: = -=3DM-x customize-variable org-link-parameters=3D +=3DM-x customize-variable org-link-mailto-program=3D = The default function called is =3Dbrowse-url=3D, which opens a mail composition buffer within Emacs. The type of buffer opened by -=3Dbrowse-url=3D depends on the setting of the variable =3Dmail-user-age= nt=3D. +browse-url depends on the setting of the variable =3Dmail-user-agent=3D.= Thus, if you want to ensure that mailto links use Gnus to open a message buffer, you could add the following to your =3D.emacs=3D: = @@ -1941,18 +1941,6 @@ message buffer, you could add the following to you= r =3D.emacs=3D: (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 =3Dmailto:=3D links in -the =3DMailMate=3D 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 --=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_= Content-Disposition: attachment; filename=0003-From-Max-Nikulin.patch Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =46rom 2fcf6bd07aa3e09cd11328e9e57cf3915c08a667 Mon Sep 17 00:00:00 2001 From: "Robert P. Goldman" 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 =3Dorg-link-mailto-program=3D: +Org calls ~browse-url~ function for =3Dmailto:=3D links, so it should ob= ey +your Emacs configuration. If something goes wrong then +[[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good start= ing 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)][=3DM-x customi= ze-variable RET browse-url-mailto-function RET=3D]] +and =3Dmailto:=3D 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 ~b= rowse-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)][=3DM-x customize-variable= RET mail-user-agent RET=3D]] to set the variable +to e.g. =3Dgnus-user-agent=3D. + +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. = -=3DM-x customize-variable org-link-mailto-program=3D - -The default function called is =3Dbrowse-url=3D, which opens a mail -composition buffer within Emacs. The type of buffer opened by -browse-url depends on the setting of the variable =3Dmail-user-agent=3D.= -Thus, if you want to ensure that mailto links use Gnus to open a -message buffer, you could add the following to your =3D.emacs=3D: +#+begin_comment +Recurring source of pain is interaction of Emacs function with +=3Dxdg-open=3D, =3Dkde-open5=3D, =3Dgio open=3D utilities on Linux. Whi= le +~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=3D9779#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=3D44824 and +https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12972 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 =3Dmailto:=3D 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)][=3DM-x customize-vari= able RET org-link-parameters RET=3D]], 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 =3D0=3D as the =3DDESTINATION=3D 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 --=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_= Content-Disposition: attachment; filename=0004-Further-edits-to-Max-Nikulin-s-patch.patch Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =46rom 9d415c3d55c3f0817598b7d746d96ae9f602623c Mon Sep 17 00:00:00 2001 From: "Robert P. Goldman" 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 =3Dmailto:=3D links, so it should ob= ey +Org calls the ~browse-url~ function for =3Dmailto:=3D links, so it shoul= d obey your Emacs configuration. If something goes wrong then [[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good start= ing 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 +=3Dnil=3D, e.g. using [[elisp:(customize-variable 'browse-url-mailto-function)][=3DM-x customi= ze-variable RET browse-url-mailto-function RET=3D]] -and =3Dmailto:=3D links will be opened accordingly to -~browse-url~browser-function~ value. +and =3Dmailto:=3D 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 ~b= rowse-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)][=3DM-x customize-variable= RET mail-user-agent RET=3D]] to set the variable -to e.g. =3Dgnus-user-agent=3D. - -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., + =3Dgnus-user-agent=3D using +[[elisp:(customize-variable 'mail-user-agent)][=3DM-x customize-variable= RET mail-user-agent RET=3D]] . + +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) si= nce 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 -=3Dxdg-open=3D, =3Dkde-open5=3D, =3Dgio open=3D utilities on Linux. Whi= le +A recurring source of pain for Emacs users is the interaction +of Emacs functions with the +=3Dxdg-open=3D, =3Dkde-open5=3D, and =3Dgio open=3D 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=3D9779#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 =3Dbrowse-url-=3D 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=3D9779#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=3D44824 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12972 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 --=_MailMate_3AFD4715-4DC4-4C20-84AD-78CD7D3D459F_=--