On 02/02/2023 01:16, Bruno Barbier wrote:
Max Nikulin writes:
On 01/02/2023 02:56, Bruno Barbier wrote:
Is it intentional that you and the linked page avoid cb_thunderlink page
on the official add-on site?
https://addons.thunderbird.net/en-us/thunderbird/addon/cb_thunderlink/
No. But visiting the author site being mandatory to install it, I
thought it was simpler to point directly there.
The author suggests to install from github assets instead of official
add-on catalog for some reason. Perhaps it is just survived since times
when cb_thunderlink was not published yet.
+#+begin_src elisp
+(defvar cbthunderlink-app nil
+ "The full path where you've installed your cb_thunderlink application.")
+
+(defun cbthunderlink-open (message-id)
+ "Open the given email. MESSAGE-ID is the message id."
+ (start-process "cb_thunderlink" " *cb_thunderlink*"
--------------------------------------^
Yes. This is a buffer that is uninteresting to the user, see:
Thank you for clarification, I forgot about it.
in both cases it promises to register thunderlink:// and
cbthunderlink:// handlers. From my point of view it may be a reason to
take advantage of `browse-url' package. It should allow to avoid
explicit code to start process and to delegate the task to this package
and to handle mid: links by `goto-address-mode' in non-org buffers.
...
I'm not using `browse-url' (except for web pages) and I wasn't aware of
`goto-address-mode'.
My idea was to push '("\\`mid:" . custom/browse-url-mid) to
`browse-url-handlers' having (untested)
(defun custom/browse-url-mid (url &optional _ignored)
(browse-url
(replace-regexp-in-string "\\`mid:" "thunderlink:/message-id=" url)))
I am unsure concerning double slash after protocol since host name
expected after double slash. At least KDE may try to resolve hostname
and to distort URI. I hope, Message-ID never contains characters that
may require percent encoding when used in query parameter value.
`browse-url-xdg-open' had a lot of revisions before current
`call-process' settled inside. It is the reason why I will prefer to
avoid explicit calls to `start-process' (alternatives known to me are
even worse) and to delegate as much as possible to `browse-url'.
By the way, if cb_thunderlink is more convenient than built-in way to
handle mid: links in thunderbird then support of mid: URI protocol is a
valid feature request for cb_thunderlink.
I'm not sure to understand. The `cb_thunderlink' add-on allow to build
the link in one click from inside Thunderbird; that the part that I find
really useful. And if Thunderbird is able to open an email from its
"mid:" URL, the prefered method should probably be to install only the
add-on inside Thunderbird, and use Thunderbird to reopen the "mid:" link.
Since you suggest thunderlink: links instead of built-in mid: (already
described in FAQ), I assume that the former approach has some advantage
over the latter. Nobody forbids to have several handlers for some
protocol and to let user decide which one their prefer, built-in or
cb_thunderlink. If cb_thunderlink configures mid: handler then it will
become available for configuration at the level of desktop environment.
