commit e151f6d800e216ba2586b309f777efed81197572 Author: Max Nikulin 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-= 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