[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v3] Fix FAQ entry about mailto links.
From: |
Max Nikulin |
Subject: |
[PATCH v3] Fix FAQ entry about mailto links. |
Date: |
Mon, 14 Feb 2022 20:22:14 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 |
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