[PATCH v3] Fix FAQ entry about mailto links.

[Max Nikulin]

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

0001-FAQ-Update-suggestion-for-mailto-link-handlers.patch
Description: Text Data

faq-mailto-changes-since-2022-02-11-goldman.diff
Description: Text Data