Link from orgmode file to E-Mail (using kmail or notmuch)

Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Hi!

Workflow: E-Mails with a question comes in, I open a TODO heading in an orgmode 
file regarding the question.

Now, I'd like to add a link to the E-Mail under this TODO heading in the 
orgmode file. I've seen the manual page about external links, https://
orgmode.org/manual/External-Links.html 

I'm on Linux, KDE as GUI, distro Tumbleweed by openSUSE. The E-mail software 
is kmail. Unfortunately, there is no way to get the path to an individual E-
mail out of kmail, which I could simply use to put it into my orgmode file as a 
link.

So I installed notmuchmail and the emacs package notmuch.el. Works. By 
notmuch-search I can find an individual E-mail. In the E-Mail buffer I type
c I , which copies the message-ID of that E-Mail into the keyring. 

Instead of a link I paste the message-ID into my orgmode file. If I'd like to 
read the E-Mail again, I can use notmuch-search: id: <abc123> to find the E-
Mail again.

I know, this is not a really efficient way. Probably you are not surprised to 
read my question:

How can I have a link in an orgmode file to an E-Mail using either a feature of 
kmail oder notmuch ?

Regards,

Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Gautier Ponsinet]

Hello Alexander,

AW <alexander.willand@t-online.de>:
> How can I have a link in an orgmode file to an E-Mail using either a feature of 
> kmail oder notmuch ?

The package "ol-notmuch" implements links to notmuch messages and "searches":
https://git.sr.ht/~tarsius/ol-notmuch .

There might be other solution, for notmuch or kmail, which I am not
aware of. I hope it helps you.

All the best,
Gautier.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 22/01/2023 04:32, AW wrote:
> 
> How can I have a link in an orgmode file to an E-Mail using either a feature of
> kmail oder notmuch ?

I am not a kmail user, but out of curiosity I spent a couple of minutes 
trying to find some way to link messages. The only result is some old 
blog post suggesting to create links to files (it seems storage format 
is maildir).

So it seems the only way to get it possible in future is to file a 
feature request to implement "mid:" URI schema

RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
https://tools.ietf.org/html/rfc2392

I was surprised that "mid:" had been reserved many years ago by

Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource 
Locators (URL)", RFC 1738, December 1994

E.g. thunderbird implemented such feature relatively recently and it 
allows me to have links like

AW to emacs-orgmode. Link from orgmode file to E-Mail (using kmail or 
notmuch) Sat, 21 Jan 2023 22:32:47 +0100. 
mid:3218434.44csPzL39Z@linux.fritz.box

in my Org files.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> AW to emacs-orgmode. Link from orgmode file to E-Mail (using kmail or 
> notmuch) Sat, 21 Jan 2023 22:32:47 +0100. 
> mid:3218434.44csPzL39Z@linux.fritz.box

My notmuch allows me to click on the above link from inside the email.
As for Org links, [[notmuch:id:3218434.44csPzL39Z@linux.fritz.box]]
works the same via ol-notmuch.

We could support mid: is the corresponding url schema existed and
supported by various OSes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-22 11:34]:
> We could support mid: is the corresponding url schema existed and
> supported by various OSes.

Instead of supporting hard coded `mid:` in Org, you better support
generally anything that users may define with variable
`browse-url-handlers` and `browse-url-default-handlers` or
`thing-at-point-uri-schemes', that way you need not need to hard code
it in Org, let it be handled on Emacs level.

Hide browse-url-handlers: 
'(("gemini:" . elpher-go)
  ("gopher:" . elpher-handler-go)
  ("about:" . hyperscope-about)
  ("mid:" . mutt-by-message-id)
  ("hyperscope:" . hyperscope-go)
  ("e2dk://" . amule-handler))

Unless it already works that way.

But on my side it opens up GUI widget telling me "No match, create
heading" -- which is wrong.

If I however, turn on M-x goto-address-mode then about:hyperscope and
mid:123 starts working automatically, it is handled by user's choice.


List of URI Schemes:
https://en.wikipedia.org/wiki/List_of_URI_schemes


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 22/01/2023 15:32, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> My notmuch allows me to click on the above link from inside the email.
> As for Org links, [[notmuch:id:3218434.44csPzL39Z@linux.fritz.box]]
> works the same via ol-notmuch.
> 
> We could support mid: is the corresponding url schema existed and
> supported by various OSes.

Does emacs support query to desktop environment if specific URI schema 
is supported? Anyway it will increase load time. Instead list of types 
for `browse-url' may be converted into a user option, currently it is 
hard coded:

(dolist (scheme '("ftp" "http" "https" "mailto" "news"))
   (org-link-set-parameters scheme
			   :follow
			   (lambda (url arg)
			     (browse-url (concat scheme ":" url) arg))))

Currently I use

(with-eval-after-load 'ol
   (org-link-set-parameters
    "mid"
    :follow (lambda (url &optional arg)
              (browse-url (concat "mid:" url) arg))))

See Org FAQ https://orgmode.org/worg/org-faq.html#org1d563f2 "Can I 
create links to Thunderbirds emails?"

I suppose, notmuch may provide a function for "mid:" associatiopn in 
`browse-url-handler' and a .desktop file similar to

http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient-mail.desktop

for handling mid: links from other applications.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Sonntag, 22. Januar 2023, 09:32:34 CET schrieb Ihor Radchenko:
> Max Nikulin <manikulin@gmail.com> writes:
> > AW to emacs-orgmode. Link from orgmode file to E-Mail (using kmail or
> > notmuch) Sat, 21 Jan 2023 22:32:47 +0100.
> > mid:3218434.44csPzL39Z@linux.fritz.box
> 
> My notmuch allows me to click on the above link from inside the email.
> As for Org links, [[notmuch:id:3218434.44csPzL39Z@linux.fritz.box]]
> works the same via ol-notmuch.
> 

Works, great, one thing solved. Thank you!

> We could support mid: is the corresponding url schema existed and
> supported by various OSes.

Isn't this rather important? How many users of orgmode get TODOs via E-Mail 
and need an efficient way to come back from the TODO to its origin?

-- 
Regards,

Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* AW <alexander.willand@t-online.de> [2023-01-22 21:49]:
> Isn't this rather important? How many users of orgmode get TODOs via E-Mail 
> and need an efficient way to come back from the TODO to its origin?

Absolutely!

There are many uses apart from tasks, there are attachments. 

Legally is better not to delete attachment from e-mail to keep it as
evidence, and references to document in the e-mail are useful.

It seem as a "forgotten" and lacking feauture in many software.

From:

TECHNOLOGY TEMPLATE PROJECT OHS Framework :
https://www.dougengelbart.org/content/view/110/460/

**** Dynamic knowledge capture, integration, management

Automated capture,  indexing and cross-referencing,  integrated email,
journal/library,  intelligence collections;  utilities for  repository
management

Sadly software designers do not follow successful principles, they
tend to follow personal or individual demands, and we get some use of
it, though we could do so much more for people.

- automated capture is missing in many software programs, as programs
  are tool centric, made to be "better" among competition, instead of
  integrating with competition.
  
  Example is Evince PDF viewer which does not have capture system. At
  least it has referencing system by page and query. While XPdf
  program has possibility to capture and reference in the same
  time. 
  
  Many PDF viewers don't have system to capture page number, query,
  some have annotations usable only from inside of the tool, without
  providing integration to other applications.
 
So it is with E-mail clients, they tend to be self-centric, not
providing information in usable way to other applications. Would they
do, there would be no such external tools like `mu' and `notmuch` for
indexing, as any information would be already indexed and re-usable by
other software (competition).

In Emacs we have that option to remember position of a cursor in some
specific file by customizing `save-place' option. That is miniscule
example of automatic capture of piece of information such as location
of a cursor, and with automatic referencing to that piece of
information so that user get to that portion of the file or text where
user was in last session. I think it should be by default. And so many
text editors do not have that basic feature.

It is good to keep filing feature requests to various software authors
that they start implementing note capturing features.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

AW <alexander.willand@t-online.de> writes:

>> We could support mid: is the corresponding url schema existed and
>> supported by various OSes.
>
> Isn't this rather important? How many users of orgmode get TODOs via E-Mail 
> and need an efficient way to come back from the TODO to its origin?

It is not up to Org. Try

 (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box") 

You will likely see nothing.

So, while Org may provide some limited help with mid:, as Max suggested,
there is no way to guarantee that mid: links will work for all users
without users hand-customizing how to open emails.

I am not even sure if we need to make Org open mid: links via
`browse-url'. Maybe it should be something else? IDK.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Montag, 23. Januar 2023, 11:40:24 CET schrieb Ihor Radchenko:
> AW <alexander.willand@t-online.de> writes:
> >> We could support mid: is the corresponding url schema existed and
> >> supported by various OSes.
> > 
> > Isn't this rather important? How many users of orgmode get TODOs via
> > E-Mail
> > and need an efficient way to come back from the TODO to its origin?
> 
> It is not up to Org. Try
> 
>  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
> 
> You will likely see nothing.

Well, M-x  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box") 
produces [No match].
> 
> So, while Org may provide some limited help with mid:, as Max suggested,
> there is no way to guarantee that mid: links will work for all users
> without users hand-customizing how to open emails.
> 
> I am not even sure if we need to make Org open mid: links via
> `browse-url'. Maybe it should be something else? IDK.

This is weird since ever. I've been talking to some collegues and everybody 
has his/her own special approach. Mostly producing a PDF from the E-Mail and 
saving this and its attachments somewhere. That's a thing that bothered me for 
decades. 

-- 
Regards,

Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* AW <alexander.willand@t-online.de> [2023-01-23 16:58]:
> Am Montag, 23. Januar 2023, 11:40:24 CET schrieb Ihor Radchenko:
> > AW <alexander.willand@t-online.de> writes:
> > >> We could support mid: is the corresponding url schema existed and
> > >> supported by various OSes.
> > > 
> > > Isn't this rather important? How many users of orgmode get TODOs via
> > > E-Mail
> > > and need an efficient way to come back from the TODO to its origin?
> > 
> > It is not up to Org. Try
> > 
> >  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
> > 
> > You will likely see nothing.
> 
> Well, M-x  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box") 
> produces [No match].

By default no match, but as already said, that depends of your
settings. 

It works on my side as I have settings for that. 

In Emacs it is up to user to set how to open it.

Same as with any Internet browser, when you try to use less used URLs,
then you will see browser is asking you by which application to open
it, if to remember that application and so on.

For example magnet: could be opened by Deluge or other torrent
applications, depending of user settings in browser.

There are too many applications and hard coding how to open message ID
would be limitation, not feature.

You may cutomize variable `browse-url-handlers' to get what you wish.

Its value is
(("gemini:" . elpher-go)
 ("gopher:" . elpher-handler-go)
 ("about:" . hyperscope-about)
 ("hyperscope:" . hyperscope-url)
 ("e2dk://" . amule-handler))




--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

AW <alexander.willand@t-online.de> writes:

>> It is not up to Org. Try
>> 
>>  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
>> 
>> You will likely see nothing.
>
> Well, M-x  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box") 
> produces [No match].

This is not a command.
You need M-: (...

>> So, while Org may provide some limited help with mid:, as Max suggested,
>> there is no way to guarantee that mid: links will work for all users
>> without users hand-customizing how to open emails.
>> 
>> I am not even sure if we need to make Org open mid: links via
>> `browse-url'. Maybe it should be something else? IDK.
>
> This is weird since ever. I've been talking to some collegues and everybody 
> has his/her own special approach. Mostly producing a PDF from the E-Mail and 
> saving this and its attachments somewhere. That's a thing that bothered me for 
> decades. 

Well. The more widely used standard is Maildir - downloading emails from
server to local machine. Emails are just files there that can be indexed
by variety of mail client software.

The main question is which email clients actually support mid: links.
notmuch does, but in non-standard way, without doing it system-wide.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Dirk-Jan C. Binnema]

On Tuesday Jan 24 2023, Ihor Radchenko wrote:

> AW <alexander.willand@t-online.de> writes:
>
>>> It is not up to Org. Try
>>> 
>>>  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
>>> 
>>> You will likely see nothing.
>>
>> Well, M-x  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box") 
>> produces [No match].
>
> This is not a command.
> You need M-: (...
>
>>> So, while Org may provide some limited help with mid:, as Max suggested,
>>> there is no way to guarantee that mid: links will work for all users
>>> without users hand-customizing how to open emails.
>>> 
>>> I am not even sure if we need to make Org open mid: links via
>>> `browse-url'. Maybe it should be something else? IDK.
>>
>> This is weird since ever. I've been talking to some collegues and everybody 
>> has his/her own special approach. Mostly producing a PDF from the E-Mail and 
>> saving this and its attachments somewhere. That's a thing that bothered me for 
>> decades. 
>
> Well. The more widely used standard is Maildir - downloading emails from
> server to local machine. Emails are just files there that can be indexed
> by variety of mail client software.
>
> The main question is which email clients actually support mid: links.
> notmuch does, but in non-standard way, without doing it system-wide.

Sorry if I'm repeating things earlier mentioned...

mu4e supports message-id links through org-mode, and I *extensively*
use that my agenda / todo lists. E.g.,
   mu4e:msgid:CACwzTKkeyptMcOA=jq8y23948-FKyfKMTwU3FA@mail.gmail.com

To make it work through browse-url (is that useful?) shouldn't be too
hard to configure `browse-url-default-handlers' for that. For mu4e that
could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
better name imho) rather than `mid'.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

"Dirk-Jan C. Binnema" <djcb.bulk@gmail.com> writes:

> Sorry if I'm repeating things earlier mentioned...
>
> mu4e supports message-id links through org-mode, and I *extensively*
> use that my agenda / todo lists. E.g.,
>    mu4e:msgid:CACwzTKkeyptMcOA=jq8y23948-FKyfKMTwU3FA@mail.gmail.com

Ideally, we need not to think which mail client to open the link in.
Be it notmuch or mu4e or some other OS email client outside Emacs.

mu4e: or notmuch: links are more specific in this regard.

> To make it work through browse-url (is that useful?) shouldn't be too
> hard to configure `browse-url-default-handlers' for that. For mu4e that
> could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
> better name imho) rather than `mid'.

mid: if a known standard, as Max pointed in the earlier message:

RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
https://tools.ietf.org/html/rfc2392

It makes more sense than arbitrary ideas not known to anyone, even if
they sound better for some users.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Dirk-Jan C. Binnema]

On Tuesday Jan 24 2023, Ihor Radchenko wrote:

>> To make it work through browse-url (is that useful?) shouldn't be too
>> hard to configure `browse-url-default-handlers' for that. For mu4e that
>> could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
>> better name imho) rather than `mid'.
>
> mid: if a known standard, as Max pointed in the earlier message:
>
> RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
> https://tools.ietf.org/html/rfc2392
>
> It makes more sense than arbitrary ideas not known to anyone, even if
> they sound better for some users.

Thanks, no arguing with that, at least not without involving a
time-machine.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-24 14:19]:
> mid: if a known standard, as Max pointed in the earlier message:
> 
> RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
> https://tools.ietf.org/html/rfc2392

It is "proposed standard" and far from any ordinary use.

> It makes more sense than arbitrary ideas not known to anyone, even
> if they sound better for some users.

Not that I can agree as heavy user of e-mails.

mid: -- shall support IMAP, mbox, Maildir, file location in first
place.

Please think of 1998, that is year where majority of people used mbox,
which meaning was that all e-mails were (mostly) in single file. 

And even with that single file, users were to open that file to
request "mid". 

This implies that e-mail program had to know which file to open.

That is missing argument to that proposed standard, practically no
standard at all, laughable to say it is "standard".

mu, notmuch and Thunderbird all use index to search for Message-ID,
including online web clients.

But location is missing part as on user's computer there may be too
many mbox, Maildir files, mh, what else, and messages may be on IMAP
server. 

I cannot provide to myself "mid:" hyperlink without providing location
of Maildir file, if I am to use Mutt as e-mail client or any e-mail
program that does not have indexing built-in.

I have to specify file plus Message-ID.

That would mean something like 

mid:///home/data1/protected/Maildir/yantar92@posteo.net&87mtz84om9.fsf@localhost

because yantar92@posteo.net would be either mbox, Maildir or other
format.

I don't care for useless and never adopted standards from 1998. 

It is 2023.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Dienstag, 24. Januar 2023, 11:42:01 CET schrieb Dirk-Jan C. Binnema:
> Sorry if I'm repeating things earlier mentioned...
> 
> mu4e supports message-id links through org-mode, and I *extensively*
> use that my agenda / todo lists. E.g.,
>    mu4e:msgid:CACwzTKkeyptMcOA=jq8y23948-FKyfKMTwU3FA@mail.gmail.com

Thank you, I'll have a look into this. Sounds good that you use it much.

> To make it work through browse-url (is that useful?) shouldn't be too
> hard to configure `browse-url-default-handlers' for that. For mu4e that
> could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
> better name imho) rather than `mid'.

From my point of view that's not necessary. I'd like to have link which opens 
an emacs buffer displaying the E-Mail. 

-- 

Regards,
Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-24 12:41]:
> > This is weird since ever. I've been talking to some collegues and everybody 
> > has his/her own special approach. Mostly producing a PDF from the E-Mail and 
> > saving this and its attachments somewhere. That's a thing that bothered me for 
> > decades. 
> 
> Well. The more widely used standard is Maildir - downloading emails from
> server to local machine. Emails are just files there that can be indexed
> by variety of mail client software.

I have to give some corrections according to my knowledge.

Maildir is less used format, not widely used. Not even in GNU/Linux,
it is simply not default. I guess mbox format is much more used.

https://en.wikipedia.org/wiki/Mbox

And it is not related to how people download or not download
e-mails. And how server uses mail boxes is also independent of how
users use mailboxes.

E-mails are not "just files", they are pieces of informaton and if
they are stored as files depends of software. When e-mail is on
server, it may run different software storing e-mails in the databases
where database objects are not independent files for each e-mail, and
can't be manipulated as such.

And retrieving e-mails, while mostly in form of files, may be also in
form of a database objects. 

There is server side and client side software, they work independent
of each other and decide how to store e-mails. Or not store it at all
at client's computer.

To understand what is widely used e-mail file format, one has to see
what are widely used e-mail clients. 

Maybe this picture may help:
https://d27jswm5an3efw.cloudfront.net/app/uploads/2021/04/most-popular-email-clients-graph.jpeg

or this one:

https://www.oberlo.com/media/1673256706-most-used-email-clients-worldwide.png?fit=max&fm=webp&w=1800

Those are by majority all web software clients.

No matter if statistics are right or wrong, not even Thunderbird is
there, and Thunderbird has Maildir only as experimental option.

And regarding indexing, many e-mail programs do not support indexing,
it is not at all their main purpose. They may retrieve e-mail, read,
reply, sort, delete, but indexing is often forgotten feature.

> The main question is which email clients actually support mid: links.
> notmuch does, but in non-standard way, without doing it system-wide.

notmuch is more indexing system, and programs working with notmuch may
be considered email clients.

Another e-mail indexing program is "mu" and I am sure it can search by
Message-ID: https://www.djcbsoftware.nl/code/mu/ as notmuch never
worked on my computer. 

I can't verify it as I did not use index, being very efficient without
it due to method of sorting all e-mails per Maildir representing the
e-mail address.

Sadly mid: appear not to be supported by many software, just as many
software not supporting various URLs when they should. 

Let us not forget there are universal URL launchers, such as:

- exo-open from XFce

- xdg-open - opens a file or URL in the user's preferred application
  (Free Desktop

- kde-open from KDE

- rox -U -- may launch any type of URI handlers by user customization:
  https://rox.sourceforge.net/desktop/book/export/html/163.html

And there are others, including browsers being mainly used to launch
any types of URI schemes.

Maybe you can see the pattern that there various launchers for URI
schemes and all of them allow users to specify which software to use,
and there are many browsers, majority of browsers follow the pattern
to allow users to specify how to open which URI scheme.

By seeing the pattern, you may see why is it useful. I hope so.

And then I hope you will not keep URI handlers hard coded, but allow
Org users to decide which launcher, browser, or what to use on Org
hyperlinks.

When I think of "mid:" I think of "Message-ID: " and that is generally
not hard to find in various e-mail formats.

In Emacs, for mbox files, it would be something as:
(search-forward "87y2e2bgzh.fsf@example.com") followed by extracting
and displaying of the found e-mail.

With Maildirs it would be `grep' search on Maildir folder, it is
almost instant on hundreds of e-mails.

Of course scalability is a problem when using `grep' as with too many
e-mails, it would last long.

That is why both for mh, mbox, Maildir and other folders, one shall
always specify the folder location.

Without folder location mid:123 alone would require indexer to find
the Message-ID.

That is why it would not be for Org to specify how mid links are
opened but for user to customize it.

As user may have mid:// format or only mid: or maybe
mid://file/message-id format, depending of the software.

That Thunderbird uses only mid:message-id format is definitely unique
and not ordinary as generally e-mail clients do not support it.

Additionally, mid: need not specify only local file, it could specify
IMAP as well mid:imaps://example.com/INBOX&message-id

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

[OT] email opens (was: Link from orgmode file to E-Mail (using kmail or notmuch))

[Gregor Zattler]

Hi Jean, org-mode developers,
* Jean Louis <bugs@gnu.support> [2023-01-24; 22:01 +03]:
> To understand what is widely used e-mail file format, one has to see
> what are widely used e-mail clients.
>
> Maybe this picture may help:
> https://d27jswm5an3efw.cloudfront.net/app/uploads/2021/04/most-popular-email-clients-graph.jpeg
>
> or this one:
>
> https://www.oberlo.com/media/1673256706-most-used-email-clients-worldwide.png?fit=max&fm=webp&w=1800

The data used in the second link actually comes from
litmus.com, they do such statistics on a regular basis.  For
the first link I cannot tell, but the numbers are very
similar to the litmus blog post on April 2021.

> Those are by majority all web software clients.

Yes, because what they are measuring is "email opens" via
web pixels and such tracking technologies.  That's might be
a reason why Thunderbird does not show up there.

So while this data somehow shows the sad state of affairs,
it is not relevant to the question of linking to emails.
Obviously Emacs caters to a tiny niche, yes.  But how does
it do or should do?

Ciao; Gregor

Re: [OT] email opens (was: Link from orgmode file to E-Mail (using kmail or notmuch))

[tomas]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Sat, Jan 28, 2023 at 03:08:17PM +0100, Gregor Zattler wrote:

[...]

> The data used in the second link actually comes from
> litmus.com, they do such statistics on a regular basis.  For
> the first link I cannot tell, but the numbers are very
> similar to the litmus blog post on April 2021.
> 
> > Those are by majority all web software clients.
> 
> Yes, because what they are measuring is "email opens" via
> web pixels and such tracking technologies [...]

They do *what*?

> So while this data somehow shows the sad state of affairs,

I'd venture it shows their incompetence. But that seems to
be a honourable way to make money these days.

Thanks for expanding my horizon...

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [OT] email opens (was: Link from orgmode file to E-Mail (using kmail or notmuch))

[Jean Louis]

* Gregor Zattler <telegraph@gmx.net> [2023-01-28 17:09]:
> Yes, because what they are measuring is "email opens" via
> web pixels and such tracking technologies.  That's might be
> a reason why Thunderbird does not show up there.
> 
> So while this data somehow shows the sad state of affairs,
> it is not relevant to the question of linking to emails.
> Obviously Emacs caters to a tiny niche, yes.  But how does
> it do or should do?

Thanks for comments.

Emacs is used by many millions of people, at least installed. Not
maybe daily used, real number of users is difficult to
determine. 

Though Emacs users of Emacs e-mail packages must be less. 

Still it must be a significant number of people.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Dienstag, 24. Januar 2023, 10:40:30 CET schrieb Ihor Radchenko:
> AW <alexander.willand@t-online.de> writes:
> >> It is not up to Org. Try
> >> 
> >>  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
> >> 
> >> You will likely see nothing.
> > 
> > Well, M-x  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
> > produces [No match].
> 
> This is not a command.
> You need M-: (...

Sorry, I'm a user, not much knowledge of elisp. However, the result now is 
'nil'. 

> >> So, while Org may provide some limited help with mid:, as Max suggested,
> >> there is no way to guarantee that mid: links will work for all users
> >> without users hand-customizing how to open emails.
> >> 
> >> I am not even sure if we need to make Org open mid: links via
> >> `browse-url'. Maybe it should be something else? IDK.
> > 
> > This is weird since ever. I've been talking to some collegues and
> > everybody
> > has his/her own special approach. Mostly producing a PDF from the E-Mail
> > and saving this and its attachments somewhere. That's a thing that
> > bothered me for decades.
> 
> Well. The more widely used standard is Maildir - downloading emails from
> server to local machine. Emails are just files there that can be indexed
> by variety of mail client software.

This is about a maildirs of kmail on my local machine. The E-Mails are being 
indexed by akonadi on the side of kde-pim. But referring to a certain E-Mail 
from orgmode with a kind of link fails, because I'd need to got to the maildir 
and search for the specific E-Mail. kde-pim does not offer an easy way to 
extract that or the message-ID. 
> 
> The main question is which email clients actually support mid: links.
> notmuch does, but in non-standard way, without doing it system-wide.

And kmail obviously does not. OK, but since I installed notmuch, notmuch.el 
and ol-notmuch.el, I will have a look into using this. Thank you!

--

Regards,

Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

AW <alexander.willand@t-online.de> writes:

>> > Well, M-x  (browse-url "mid:3218434.44csPzL39Z@linux.fritz.box")
>> > produces [No match].
>> 
>> This is not a command.
>> You need M-: (...
>
> Sorry, I'm a user, not much knowledge of elisp. However, the result now is 
> 'nil'. 

On my side, it returns nil and _also_ opens mid:... url in browser. It
might also display an app selection dialogue, depending on your DM.
Did anything like I described happen on your side?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 26/01/2023 16:58, AW wrote:
> This is about a maildirs of kmail on my local machine. The E-Mails are being
> indexed by akonadi on the side of kde-pim.

Are you able to search messages through the KDE (global) dialog? Does it 
work if you try to find some Message-ID? Perhaps it is necessary to add 
more sources for searches in the dialog configuration. If Message-ID 
header is indexed then it might be possible to launch such search from Org.

Sorry, I do not use kmail or KDE indexers, so I am not enough motivated 
to check it myself. It just an idea, perhaps it leads to nothing.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* AW <alexander.willand@t-online.de> [2023-01-26 13:00]:
> This is about a maildirs of kmail on my local machine. The E-Mails are being 
> indexed by akonadi on the side of kde-pim. But referring to a certain E-Mail 
> from orgmode with a kind of link fails, because I'd need to got to the maildir 
> and search for the specific E-Mail. kde-pim does not offer an easy way to 
> extract that or the message-ID. 

How many Maildirs do you have?

and what does program:

akonadi_maildir_resource does?

Should it find e-mail?

Without Akonadi:
----------------

Solution may be simple without akonadi and external software.

It would be to provide main Maildir, then for program to find
submaildirs, and to find Message ID in every e-mail, and record it,
once per day, of course with e-mail file or folder location plus
Message ID. This is simple program and can be done in shell or Emacs
Lisp, collecting all Message IDs efficiently from every Maildir.

This program thus can be universal program, and then function can
decide how to open e-mail, and it is just fine opening e-mail in Emacs
as well.

Same program could be used to find e-mails by name or sender, or
recipient.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Donnerstag, 26. Januar 2023, 13:18:49 CET schrieb Jean Louis:
> * AW <alexander.willand@t-online.de> [2023-01-26 13:00]:
> > This is about a maildirs of kmail on my local machine. The E-Mails are
> > being indexed by akonadi on the side of kde-pim. But referring to a
> > certain E-Mail from orgmode with a kind of link fails, because I'd need
> > to got to the maildir and search for the specific E-Mail. kde-pim does
> > not offer an easy way to extract that or the message-ID.
> 
> How many Maildirs do you have?

One main, a hundred submaildirs.

> 
> and what does program:
> 
> akonadi_maildir_resource does?
> 
> Should it find e-mail?

Akonadi is a part of kde-pim.

> Without Akonadi:
> ----------------
> 
> Solution may be simple without akonadi and external software.
> 
> It would be to provide main Maildir, then for program to find
> submaildirs, and to find Message ID in every e-mail, and record it,
> once per day, of course with e-mail file or folder location plus
> Message ID. This is simple program and can be done in shell or Emacs
> Lisp, collecting all Message IDs efficiently from every Maildir.
> 
> This program thus can be universal program, and then function can
> decide how to open e-mail, and it is just fine opening e-mail in Emacs
> as well.
> 
> Same program could be used to find e-mails by name or sender, or
> recipient.
Yes, that's what I'm doing with notmuch, thanks to the hint that ol-notmuch 
provides notmuch-search with message-ID. So far, my issue is solved. 

-- 

Regards,

Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 23/01/2023 01:47, AW wrote:
>> We could support mid: is the corresponding url schema existed and
>> supported by various OSes.
> Isn't this rather important? How many users of orgmode get TODOs via E-Mail
> and need an efficient way to come back from the TODO to its origin?

I agree that linking mail messages and Org notes is important. On the 
other hand my impression is that the "mid:" URI protocol is not adopted 
wide enough by mail user agents yet, so it is too early to enable it by 
default in Org.

Configuring of "mid:" links requires just a few lines in init.el and 
they are quite usual for custom links.

Alexander, you have tried 2 mail application and it seems neither of 
them supports "mid:" links out of the box. Notmuch looks almost ready, 
it needs just a .desktop file and configuring `browse-url-handlers' on 
activation. Have you checked if kmail bug tracker has a feature request 
for "mid:" links? I am not sure that KDE bug trackers are indexed by 
search engines.

 From the blog post by Karl Voit I have an impression that developers of 
Evolution do not follow RFC since posted command example contains angle 
brackets (mid:<...@...>). Such format causes "not found" error in 
Thunderbird.

On 23/01/2023 17:40, Ihor Radchenko wrote:
> I am not even sure if we need to make Org open mid: links via
> `browse-url'. Maybe it should be something else? IDK.

Do you know an alternative? Org already uses this package to open some 
types of links. It allows to have the same handler for all Emacs 
packages. I do not think that Org-specific handler would be better.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Montag, 23. Januar 2023, 12:46:38 CET schrieb Max Nikulin:
> On 23/01/2023 01:47, AW wrote:
> >> We could support mid: is the corresponding url schema existed and
> >> supported by various OSes.
> > 
> > Isn't this rather important? How many users of orgmode get TODOs via
> > E-Mail
> > and need an efficient way to come back from the TODO to its origin?
> 
> I agree that linking mail messages and Org notes is important. On the
> other hand my impression is that the "mid:" URI protocol is not adopted
> wide enough by mail user agents yet, so it is too early to enable it by
> default in Org.
> 
> Configuring of "mid:" links requires just a few lines in init.el and
> they are quite usual for custom links.
> 
> Alexander, you have tried 2 mail application and it seems neither of
> them supports "mid:" links out of the box. Notmuch looks almost ready,
> it needs just a .desktop file and configuring `browse-url-handlers' on
> activation. Have you checked if kmail bug tracker has a feature request
> for "mid:" links? I am not sure that KDE bug trackers are indexed by
> search engines.

I have done that now without result. But I'll write an E-Mail to the 
developers of kmail. 
> 
>  From the blog post by Karl Voit I have an impression that developers of
> Evolution do not follow RFC since posted command example contains angle
> brackets (mid:<...@...>). Such format causes "not found" error in
> Thunderbird.
> 
> On 23/01/2023 17:40, Ihor Radchenko wrote:
> > I am not even sure if we need to make Org open mid: links via
> > `browse-url'. Maybe it should be something else? IDK.
> 
> Do you know an alternative? Org already uses this package to open some
> types of links. It allows to have the same handler for all Emacs
> packages. I do not think that Org-specific handler would be better.

As long as notmuch, notmuch.el and ol-notmuch are there we have a viable 
solution, thanks to this (undocumented) trick with notmuch:id:123abc, after 
getting the id by opening the mail with notmuch in emacs and »c I«. 

Thank you for your time and effort!

-- 
Regards,
Alexander

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Am Montag, 23. Januar 2023, 14:59:12 CET schrieb AW:
> But I'll write an E-Mail to the
> developers of kmail.


https://bugs.kde.org/show_bug.cgi?id=464695

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

AW <alexander.willand@t-online.de> writes:

> As long as notmuch, notmuch.el and ol-notmuch are there we have a viable 
> solution, thanks to this (undocumented) trick with notmuch:id:123abc

This is not undocumented. ol-notmuch provides notmuch:<search-term>
links. id:message-id is a valid search term in notmuch. See
https://notmuchmail.org/searching/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 23/01/2023 20:59, AW wrote:
> I have done that now without result. But I'll write an E-Mail to the
> developers of kmail.

Thank you for filing a feature request.

> As long as notmuch, notmuch.el and ol-notmuch are there we have a viable
> solution, thanks to this (undocumented) trick with notmuch:id:123abc, after
> getting the id by opening the mail with notmuch in emacs and »c I«.

Less than dozen lines of code in init.el (configure mid: links in Org 
and install notmuch handler for `browse-url') should allow referencing 
messages in a MUA agnostic way at least by Message-ID. Emacs mail 
clients allows other queries, but likely there is no standard for them.

> This is weird since ever. I've been talking to some collegues and everybody 
> has his/her own special approach. Mostly producing a PDF from the E-Mail and 
> saving this and its attachments somewhere. That's a thing that bothered me for 
> decades. 

Thunderbird allows to save messages as an .eml file and to open it by

thunderbird /tmp/test.eml

Gmail web application allows .eml export as well. In some cases it is an 
alternative to PDF.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Max Nikulin <manikulin@gmail.com> writes:

> Thunderbird allows to save messages as an .eml file and to open it by
> thunderbird /tmp/test.eml

I'm using an extension for Thunderbird that allows to copy a direct link to a
message. I then paste it into a org file so that I can reopen the
message in one click:

   https://camiel.bouchier.be/en/cb_thunderlink


Bruno

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 25/01/2023 00:32, Bruno Barbier wrote:
> 
> I'm using an extension for Thunderbird that allows to copy a direct link to a
> message. I then paste it into a org file so that I can reopen the
> message in one click:
> 
>     https://camiel.bouchier.be/en/cb_thunderlink

Perhaps I found this add-on too early. I had a look into its code and 
decided to find another way. Another point is that I prefer to have 
Message-ID in links not obscured. Fortunately I noticed the issue 
dedicated to "mid:" in the bug tracker.

Some minor inconveniences exist, but I do not plan to discard mid: 
links. E.g. I can easily convert links to messages in this list between 
mid: and https://list.orgmode.org/

I decided that it should be convenient to have links from thunderbird to 
my notes. A proof of concept:

https://github.com/maxnikulin/orco/

Max Nikulin to emacs-orgmode. Org Column in Thunderbird. Wed, 8 Jun 2022 
20:11:33 +0700. https://list.orgmode.org/t7q766$m5k$1@ciao.gmane.io

If Message-ID still can be decoded from cb_thinderlink URIs than it 
should be possible adapt orco to handle such links as well.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 28/01/2023 01:15, Bruno Barbier wrote:
> 
>>> If Message-ID still can be decoded from cb_thinderlink URIs than it
>>> should be possible adapt orco to handle such links as well.
> 
> I'm using plain Message-IDs to identify my emails, and, when choosing an
> email client, that's really the first feature that I'm checking.
> 
> In Thunderbird, in the cb_thunderlink config (v 1.6.0), I'm using a link format
> that is compatible with the old thunderlink extension:
> 
>       [[email:$msgid$][$author_name$: $subject$ ($date_iso$)]]

Notice that you can use mid:$msgid$ instead of email:$msgid$.

     thunderbird 'mid:tqr8et$mrc$1@ciao.gmane.io'

opens the message in a new tab or a new window. Sometimes separate tab 
is inconvenient, but context menu has "show message in containing 
folder" item. ESR releases 91 and 102 support it out of the box. Whether 
thunderbird.desktop contains "x-scheme-handler/mid;" in the MimeType 
parameter (and so desktop-wide integration out of the box) depends on 
particular Linux distribution. For emacs it means that (browse-url 
"mid:tqr8et$mrc$1@ciao.gmane.io") should just work.

> To open a message whose "Message-ID" is 'message-id', org just
> requests my operating system to open a link like:
> 
>       (concat "thunderlink://messageid=" message-id)

This approach can be used with "mid:" scheme for links in Org files as well.

> It looks like thunderbird allows to search for Message-ID (see
> headerMessageId):
> 
>     https://webextension-api.thunderbird.net/en/stable/messages.html#messages-query
>     
> and there is no warning about using it. I'm guessing that cb_thunderlink
> is using this.

There was a lag between thunderbird-78 and some later version when there 
was no easy access to Message-ID header in add-on API. Likely it is a 
reason why cb_thunderlink has a warning that such links might be broken 
in future. I have not checked if standard API or custom low level code 
is currently used in cb_thuderlink for lookup by Message-ID.

In orco standard messages.query() is used to search for Message-IDs 
extracted from links, e.g. 
https://list.orgmode.org/t7q766$m5k$1@ciao.gmane.io It is convenient to 
see message subject and date without leaving thunderbird. The main point 
of orco is opposite mapping. It makes possible to open in emacs the 
location in file that has link to current mail message.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Max Nikulin <manikulin@gmail.com> writes:


> Notice that you can use mid:$msgid$ instead of email:$msgid$.
>
>      thunderbird 'mid:tqr8et$mrc$1@ciao.gmane.io'

Yes. I realized that from previous emails in this thread. I should be
using 'mid' from now on. Thanks.

> The main point 
> of orco is opposite mapping. It makes possible to open in emacs the 
> location in file that has link to current mail message.

That's definitely a nice feature. Thanks for sharing the link to this
extension.

Bruno

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

Bruno, as a cb_thunderbird user, would you like to share your experience 
and to expand

https://orgmode.org/worg/org-faq.html#orgc6f8478
10.8. Can I create links to Thunderbirds emails?

by adding a brief description of this add-on?

PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Max Nikulin <manikulin@gmail.com> writes:

> Bruno, as a cb_thunderbird user, would you like to share your experience 
> and to expand
>
> https://orgmode.org/worg/org-faq.html#orgc6f8478
> 10.8. Can I create links to Thunderbirds emails?
>
> by adding a brief description of this add-on?

Hi Max,

I've got an initial draft. It's not exactly what I'm using, as I tried
to make the configuration OS agnostic. And I'm using Thunderbird only
for accounts where I'm forced to use Win32 (else, I'm using notmuch).

I just added a section about cb_thunderlink. I'm not sure how to
organize things with the other information about Thunderbird. And, I'm
not sure about how to properly format names, etc. for the wiki.

See the attached patch.

What do you think ?

Bruno



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Add info about cb_thunderlink --]
[-- Type: text/x-diff, Size: 2361 bytes --]

From 4beb7ee307544be868a0d058763aa61558f0701b Mon Sep 17 00:00:00 2001
From: Bruno BARBIER <brubar.cs@gmail.com>
Date: Tue, 31 Jan 2023 20:33:22 +0100
Subject: [PATCH] org-faq: links with thunderbird: Add cb_thunderlink

---
 org-faq.org | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/org-faq.org b/org-faq.org
index 0410d368..1aaa3f2a 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -2051,6 +2051,54 @@ so the following recipe is obsolete:
 Notice that this link uses Message-ID to reference a particular
 message as well.
 
+*** Using the =cb_thunderlink= add-on
+The add-on =cb_thunderlink= for Thunderbird allows:
+   1. to generate direct links from emails inside Thunderbird,
+   2. and to reopen the emails following these links.
+
+**** Installation
+To install the =cb_thunderlink=, see this web page:
+
+   https://camiel.bouchier.be/en/cb_thunderlink/installation?with_menu=1
+
+You need to install both the add-on and the OS integration.
+
+Once everything is installed, follow the steps below to make org
+compatible links in Thunderbird, and to teach org how to open these
+links.
+
+**** Copying links from Thunderbird
+In Thunderbird, open the =Options= page for the =cb_thunderlink= add-on
+and add a new link type named =org= in the =Configurable links= section.
+
+#+begin_example
+[[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]
+#+end_example
+
+To get an org link for a given email, open the contextual menu, click
+the =cb_thunderlink= entry and choose the entry named =org=. This
+copies, into the clipboard, a link to this email; you can then paste
+it in Emacs.
+
+
+**** Opening the emails from Emacs
+To teach org how to open these links, add the following lines in
+your configuration file, configuring the variable
+=cbthunderlink-app= to match your system.
+
+#+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*"
+                 cbthunderlink-app
+                 (concat "thunderlink://messageid=" message-id)))
+(org-add-link-type "mid" 'org-email-open)
+#+end_src
+
+
 * Plain Lists
   :PROPERTIES:
   :CUSTOM_ID: Plain-Lists
-- 
2.39.1

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 01/02/2023 02:56, Bruno Barbier wrote:
> I've got an initial draft. It's not exactly what I'm using, as I tried
> to make the configuration OS agnostic. And I'm using Thunderbird only
> for accounts where I'm forced to use Win32 (else, I'm using notmuch).

Thank you, Bruno.

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/

> +To install the =cb_thunderlink=, see this web page:
> +
> +   https://camiel.bouchier.be/en/cb_thunderlink/installation?with_menu=1
> +
> +You need to install both the add-on and the OS integration.

Often I prefer to see URL I am going to visit, however in this case I 
would consider in-text link with description text hiding the address.

> +#+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*"
--------------------------------------^
is it intentional space?
> +                 cbthunderlink-app
> +                 (concat "thunderlink://messageid=" message-id)))
> +(org-add-link-type "mid" 'org-email-open)
> +#+end_src

I am in doubts if `org-add-link-type' should be recommended since

(make-obsolete 'org-add-link-type "use `org-link-set-parameters' 
instead." "9.0")

I checked
https://camiel.bouchier.be/en/cb_thunderlink/installation/windows
https://camiel.bouchier.be/en/cb_thunderlink/installation/linux
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.

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.

Let's wait several days, there is a chance that somebody else will add 
more comments.

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

Max Nikulin <manikulin@gmail.com> 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.

>> +To install the =cb_thunderlink=, see this web page:
>> +
>> +   https://camiel.bouchier.be/en/cb_thunderlink/installation?with_menu=1
>> +
>> +You need to install both the add-on and the OS integration.
>
> Often I prefer to see URL I am going to visit, however in this case I 
> would consider in-text link with description text hiding the address.

ok.

>> +#+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:

  (info "(elisp) Buffer Names")



> is it intentional space?
>> +                 cbthunderlink-app
>> +                 (concat "thunderlink://messageid=" message-id)))
>> +(org-add-link-type "mid" 'org-email-open)
>> +#+end_src
>
> I am in doubts if `org-add-link-type' should be recommended since
>
> (make-obsolete 'org-add-link-type "use `org-link-set-parameters' 
> instead." "9.0")

Oops. Right. I should change that, thanks (and use my new function name
`cbthunderlink-open', not the old one `org-email-open').

>
> I checked
> https://camiel.bouchier.be/en/cb_thunderlink/installation/windows
> https://camiel.bouchier.be/en/cb_thunderlink/installation/linux
> 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.

That is what I first thought. But, I couldn't find an Emacs function
that would pass that URL to the OS desktop, asking it to open the
document.

I'm not using `browse-url' (except for web pages) and I wasn't aware of
`goto-address-mode'.

> 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.

>
> Let's wait several days, there is a chance that somebody else will add 
> more comments.

ok. Thanks for your comments.

Bruno

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

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.

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]


Hi Max,

Max Nikulin <manikulin@gmail.com> writes:

> 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.

My new version instructs to install the add-on from Thunderbird, with no
OS installation. It's simpler and safer.

>
> 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'.

My new version instructs to use standard "mid:" by just running Thunderbird.


> Since you suggest thunderlink: links instead of built-in mid:

I didn't realize that Thunderbird allows to open "mid:". I've simplified
the method.

I'm now using =cb_thunderlink= just to answer the following question, that
currently is on the wiki page:

      you need to copy the value of the Message-ID
      header, it should be possible with some add-on.

i.e. cb_thunderlink allows to build a full org link (link + description).

As it's still not clear to me how to configure browse-url, I'm still relying
on start-process.

See a new version of the patch.

Bruno


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: worg-faq: cb_thunderlink --]
[-- Type: text/x-diff, Size: 1973 bytes --]

From 89cef9d7acd85828ddfbb1375fac1e805bd03cea Mon Sep 17 00:00:00 2001
From: Bruno BARBIER <brubar.cs@gmail.com>
Date: Tue, 31 Jan 2023 20:33:22 +0100
Subject: [PATCH] org-faq: links with thunderbird: Add cb_thunderlink

---
 org-faq.org | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/org-faq.org b/org-faq.org
index 0410d368..4c2d0c8f 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -2051,6 +2051,42 @@ so the following recipe is obsolete:
 Notice that this link uses Message-ID to reference a particular
 message as well.
 
+*** Using the =cb_thunderlink= add-on
+The add-on =cb_thunderlink= for Thunderbird allows to generate direct
+links from emails inside Thunderbird. You can then teach org to repon
+these links.
+
+  1. In Thunderbird, install the =cb_thunderlink= add-on.
+
+  2. In the options page of the =cb_thunderlink= add-on, add a new link
+     type, name it =org= with the following value:
+
+          #+begin_example
+          [[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]
+          #+end_example
+
+  3. In your emacs init file, add the following lines:
+          #+begin_src elisp
+          (defvar thunderbird-app nil
+            "The absolute path to your thunderbird application.")
+
+          (defun thunderbird-message-with-id (message-id)
+            "Open the given email. MESSAGE-ID is the message id."
+            (start-process "thunderbird" " *thunderbird*"
+                           thunderbird-app
+                           (concat "mid:" message-id)))
+
+          (org-link-set-parameters "mid" :follow 'thunderbird-open-message-with-id)
+          #+end_src
+
+
+In Thunderbird, to copy a link to an email into the clipboard, open
+the contextual menu, click the =cb_thunderlink= entry and choose the
+entry named =org=. Then paste the link in your org file, and, click it
+to re-open the email.
+
+
+
 * Plain Lists
   :PROPERTIES:
   :CUSTOM_ID: Plain-Lists
-- 
2.39.1

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 02/02/2023 13:04, Bruno Barbier wrote:
> As it's still not clear to me how to configure browse-url, I'm still relying
> on start-process.

Bruno, it seems I completely confused you by my comments. I am sorry for 
that.

Does the method currently suggested by FAQ works for you? My particular 
interest caused by your words that you use Thunderbird on Windows:

(with-eval-after-load 'ol
   (org-link-set-parameters
    "mid"
    :follow (lambda (url &optional arg)
              (browse-url (concat "mid:" url) arg))))

Thunderbird opens mid: links in new message display tab or window. Does 
cb_thunderlink behave in the same way or it switches to proper folder 
and selects the message in the list of messages, so it appears in 3 pane 
view making other messages from the same thread directly accessible?

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

Max Nikulin <manikulin@gmail.com> writes:

> On 02/02/2023 13:04, Bruno Barbier wrote:
>> As it's still not clear to me how to configure browse-url, I'm still relying
>> on start-process.
>
> Bruno, it seems I completely confused you by my comments. I am sorry for 
> that.

I was confused way before, trying to assemble a simple non-obsolete, not
OS specific method. No problem ;-)

> Does the method currently suggested by FAQ works for you? My particular 
> interest caused by your words that you use Thunderbird on Windows:
>
> (with-eval-after-load 'ol
>    (org-link-set-parameters
>     "mid"
>     :follow (lambda (url &optional arg)
>               (browse-url (concat "mid:" url) arg))))
>
> Thunderbird opens mid: links in new message display tab or window.
Yes. If `browse-url' knows how to open Thunderbird (mine didn't).

> Does cb_thunderlink behave in the same way or it switches to proper
> folder and selects the message in the list of messages, so it appears
> in 3 pane view making other messages from the same thread directly
> accessible?

AFAIK, cb_thunderlink behaves like Thunderbird to open messages. Once
the message is displayed, you have to click in Thunderbird to see it in
its folder or in its conversation. That's why I removed my
cb_thunderlink native application; I will use only the add-on from now
on.

My own configuration is now a lot simpler. Thanks!


How do you think we should proceed to update the wiki ?


Bruno

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 03/02/2023 22:42, Bruno Barbier wrote:
> Max Nikulin writes:
>> (with-eval-after-load 'ol
>>     (org-link-set-parameters
>>      "mid"
>>      :follow (lambda (url &optional arg)
>>                (browse-url (concat "mid:" url) arg))))
>>
>> Thunderbird opens mid: links in new message display tab or window.
> Yes. If `browse-url' knows how to open Thunderbird (mine didn't).

On windows I expect fallback to `browse-url-default-windows-browser` by 
default. Are you able to open mid: links from e.g. cmd.exe?

     open "mid:63dd2b57.050a0220.ed66f.0117@mx.google.com"

Looking into https://bugzilla.mozilla.org/show_bug.cgi?id=1696218
"Thunderbird displays the dialog for default application after each startup"
and the patch, I expect that thunderbird on windows can register 
protocol handler for the "mid" scheme.

Unsure however if the following entries in advanced preferences are 
relevant:

network.protocol-handler.expose.mid	true	
network.protocol-handler.external.mid	false

I have never debugged protocol handlers on windows. I would compare 
"mailto" and "mid" entries in the registry

https://stackoverflow.com/questions/80650/how-do-i-register-a-custom-url-protocol-in-windows

> How do you think we should proceed to update the wiki ?

I am trying to determine if it is difficult to get mid scheme working 
system-wide and emacs-wide on windows. If not, I would just add your 
example "[[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]" to the 
remark related to copying Message-ID in the existing text and corrected 
a bit a note on obsolete thunderlink. If thunderbird still has issues 
with registering global mid: handler then your snippet with 
`start-process' should be added.

Maybe I just have gone too far trying to add "right" recommendation.

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

Hi Max,

Max Nikulin <manikulin@gmail.com> writes:

> I am trying to determine if it is difficult to get mid scheme working 
> system-wide and emacs-wide on windows. If not, I would just add your 
> example "[[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]" to the 
> remark related to copying Message-ID in the existing text and corrected 
> a bit a note on obsolete thunderlink.

After asking Thunderbird to register itself as the default mail
application, "mid:" seems to be working from everywhere.

I tested with a command like:

     start "mid:63dd2b57.....gle.com"

And, I also tested:

     (browse-url-default-windows-browser "mid:63dd2b5....google.com")

That's way better than a hard-coded call to `start-process' indeed.

Thanks a lot,

Bruno

[PATCH] worg/org-faq.org: Recommend cb_thunderlink Thunderbird add-on

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On 06/02/2023 18:46, Bruno Barbier wrote:
> 
> After asking Thunderbird to register itself as the default mail
> application, "mid:" seems to be working from everywhere.

A have prepared an alternative patch. Let me know if have suggestions, 
objections, or if you prefer to proceed with another revision of your patch.

It seems you had no plan to polish your Org and system configuration to 
such degree.

[-- Attachment #2: 0001-org-faq.org-Recommend-cb_thunderlink-Thunderbird-add.patch --]
[-- Type: text/x-patch, Size: 4123 bytes --]

From a1b3a81bbc11fd2f55096cc2e29f97797b80b915 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Tue, 7 Feb 2023 21:49:06 +0700
Subject: [PATCH] org-faq.org: Recommend cb_thunderlink Thunderbird add-on

* org-faq.org (Thunderbird emails): Add CUSTOM_ID property to have
stable anchor during HTML export.  Recommend cb_thunderlink extension as a
means to generate mid: links and to handle existing thunderlink: ones.
Add a note that on Windows Thunderbird should register itself as a
handler of the mid: protocol.

Thanks to Bruno Barbier for discussion on the emacs-orgmode
mailing list.
---
 org-faq.org | 37 +++++++++++++++++++++++++++++--------
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 0410d368..a7db75c1 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1999,13 +1999,16 @@ ** Can I use CamelCase links?
 consult the [[https://orgmode.org/worg/org-contrib/org-wikinodes.html][documentation]].
 
 ** Can I create links to Thunderbirds emails?
+:PROPERTIES:
+:CUSTOM_ID: mid-url-handler
+:END:
 
 Thunderbird-91 and later versions support =mid:= URI scheme proposed
-many years ago, see
-[[https://www.rfc-editor.org/rfc/rfc2392.html][RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]]
-for details.  To create a link you need to copy the value of the
-Message-ID header, it should be possible with some add-on.  As the
-last resort you may obtain the identifier by opening message source
+many years ago in
+[[https://www.rfc-editor.org/rfc/rfc2392.html][RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]].
+To create a link you need to copy the value of the Message-ID header.
+It requires installing some add-on, see =cb_thunderlink= example below.
+As the last resort you may obtain the identifier by opening message source
 (=Ctrl+U=).  Message-ID resembles email address but has a unique
 string in the local (user) part.  Remove angle brackets and prepend
 the inner part with =mid:= to create a link.  A command to open the
@@ -2034,6 +2037,10 @@ ** Can I create links to Thunderbirds emails?
 [Default Applications]
 x-scheme-handler/mid=thunderbird.desktop;
 #+END_EXAMPLE
+On Windows ensure that Thunderbird is installed as default handler
+for URI protocols related to mail.  This approach allows to have
+uniform handler withing Emacs, including
+[[https://www.gnu.org/software/emacs/manual/html_node/emacs/Goto-Address-mode.html][~goto-address-mode~]].
 
 Instead of calling ~browse-url~ and setting up the scheme handler
 you may launch thunderbird directly.  It is a bit tricky in Emacs,
@@ -2044,12 +2051,26 @@ ** Can I create links to Thunderbirds emails?
 the link:
 : thunderbird -mail 'imap-message://USER_NAME%40gmail.com@imap.googlemail.com/INBOX?messageId=ka42mn$mn9$1@ger.gmane.org'
 
+There is
+[[https://addons.thunderbird.net/thunderbird/addon/cb_thunderlink/][=cb_thunderlink= Thunderbird add-on]]
+that allows to generate links accordingly to configurable template, e.g.
+: [[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]
+See the
+[[https://list.orgmode.org/63d01412.050a0220.9611.9c4d@mx.google.com/][discussion]]
+on the emacs-orgmode mailing list.
+Additionally the extension may open messages using =thunderlink:=
+and =cbthunderlink:= protocols however it requires installing
+of a helper application.  These URI schemes may be registered in Org
+just as it is suggested for =mid:= links above.
+
 The ThunderLink add-on recommended earlier did not work since
-transition of Thunderbird from XUL add-ons to WebExtensions,
+transition of Thunderbird-78 from XUL add-ons to WebExtensions,
 so the following recipe is obsolete:
 [[http://list.orgmode.org/ka42mn$mn9$1@ger.gmane.org][from Christoph Herzog: Re: Linking to Thunderbird (correction)]].
-Notice that this link uses Message-ID to reference a particular
-message as well.
+To open earlier created =thunderlink:= links either
+install =cb_thunderlink= add-on or add to ~browse-url-handlers~ alist
+a function that extracts Message-ID and passes it to =mid:= protocol
+handler.
 
 * Plain Lists
   :PROPERTIES:
-- 
2.25.1

Re: [PATCH] worg/org-faq.org: Recommend cb_thunderlink Thunderbird add-on

[Bruno Barbier]

Hi Max,

Max Nikulin <manikulin@gmail.com> writes:
> A have prepared an alternative patch. Let me know if have suggestions, 
> objections, or if you prefer to proceed with another revision of your
> patch.

Looks good to me.

> It seems you had no plan to polish your Org and system configuration to 
> such degree.

Not that one, that I'm using only when forced to use win32!
(else, I'm a very happy user of notmuch)

Thanks Max!

Bruno


> From a1b3a81bbc11fd2f55096cc2e29f97797b80b915 Mon Sep 17 00:00:00 2001
> From: Max Nikulin <manikulin@gmail.com>
> Date: Tue, 7 Feb 2023 21:49:06 +0700
> Subject: [PATCH] org-faq.org: Recommend cb_thunderlink Thunderbird add-on
>
> * org-faq.org (Thunderbird emails): Add CUSTOM_ID property to have
> stable anchor during HTML export.  Recommend cb_thunderlink extension as a
> means to generate mid: links and to handle existing thunderlink: ones.
> Add a note that on Windows Thunderbird should register itself as a
> handler of the mid: protocol.
>
> Thanks to Bruno Barbier for discussion on the emacs-orgmode
> mailing list.
> ---
>  org-faq.org | 37 +++++++++++++++++++++++++++++--------
>  1 file changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/org-faq.org b/org-faq.org
> index 0410d368..a7db75c1 100644
> --- a/org-faq.org
> +++ b/org-faq.org
> @@ -1999,13 +1999,16 @@ ** Can I use CamelCase links?
>  consult the [[https://orgmode.org/worg/org-contrib/org-wikinodes.html][documentation]].
>  
>  ** Can I create links to Thunderbirds emails?
> +:PROPERTIES:
> +:CUSTOM_ID: mid-url-handler
> +:END:
>  
>  Thunderbird-91 and later versions support =mid:= URI scheme proposed
> -many years ago, see
> -[[https://www.rfc-editor.org/rfc/rfc2392.html][RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]]
> -for details.  To create a link you need to copy the value of the
> -Message-ID header, it should be possible with some add-on.  As the
> -last resort you may obtain the identifier by opening message source
> +many years ago in
> +[[https://www.rfc-editor.org/rfc/rfc2392.html][RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]].
> +To create a link you need to copy the value of the Message-ID header.
> +It requires installing some add-on, see =cb_thunderlink= example below.
> +As the last resort you may obtain the identifier by opening message source
>  (=Ctrl+U=).  Message-ID resembles email address but has a unique
>  string in the local (user) part.  Remove angle brackets and prepend
>  the inner part with =mid:= to create a link.  A command to open the
> @@ -2034,6 +2037,10 @@ ** Can I create links to Thunderbirds emails?
>  [Default Applications]
>  x-scheme-handler/mid=thunderbird.desktop;
>  #+END_EXAMPLE
> +On Windows ensure that Thunderbird is installed as default handler
> +for URI protocols related to mail.  This approach allows to have
> +uniform handler withing Emacs, including
> +[[https://www.gnu.org/software/emacs/manual/html_node/emacs/Goto-Address-mode.html][~goto-address-mode~]].
>  
>  Instead of calling ~browse-url~ and setting up the scheme handler
>  you may launch thunderbird directly.  It is a bit tricky in Emacs,
> @@ -2044,12 +2051,26 @@ ** Can I create links to Thunderbirds emails?
>  the link:
>  : thunderbird -mail 'imap-message://USER_NAME%40gmail.com@imap.googlemail.com/INBOX?messageId=ka42mn$mn9$1@ger.gmane.org'
>  
> +There is
> +[[https://addons.thunderbird.net/thunderbird/addon/cb_thunderlink/][=cb_thunderlink= Thunderbird add-on]]
> +that allows to generate links accordingly to configurable template, e.g.
> +: [[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]
> +See the
> +[[https://list.orgmode.org/63d01412.050a0220.9611.9c4d@mx.google.com/][discussion]]
> +on the emacs-orgmode mailing list.
> +Additionally the extension may open messages using =thunderlink:=
> +and =cbthunderlink:= protocols however it requires installing
> +of a helper application.  These URI schemes may be registered in Org
> +just as it is suggested for =mid:= links above.
> +
>  The ThunderLink add-on recommended earlier did not work since
> -transition of Thunderbird from XUL add-ons to WebExtensions,
> +transition of Thunderbird-78 from XUL add-ons to WebExtensions,
>  so the following recipe is obsolete:
>  [[http://list.orgmode.org/ka42mn$mn9$1@ger.gmane.org][from Christoph Herzog: Re: Linking to Thunderbird (correction)]].
> -Notice that this link uses Message-ID to reference a particular
> -message as well.
> +To open earlier created =thunderlink:= links either
> +install =cb_thunderlink= add-on or add to ~browse-url-handlers~ alist
> +a function that extracts Message-ID and passes it to =mid:= protocol
> +handler.
>  
>  * Plain Lists
>    :PROPERTIES:
> -- 
> 2.25.1

Re: [PATCH] worg/org-faq.org: Recommend cb_thunderlink Thunderbird add-on

[Max Nikulin]

On 08/02/2023 01:26, Bruno Barbier wrote:
> Max Nikulin writes:
>> A have prepared an alternative patch. Let me know if have suggestions,
>> objections, or if you prefer to proceed with another revision of your
>> patch.
> 
> Looks good to me.

Thank you for your patience. Updated version:
https://orgmode.org/worg/org-faq.html#mid-url-handler

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-23 14:49]:
> I agree that linking mail messages and Org notes is important. On the other
> hand my impression is that the "mid:" URI protocol is not adopted wide
> enough by mail user agents yet, so it is too early to enable it by default
> in Org.

All URLs defined by Emacs that are to be run by browse-url in Org
shall be allowed by org, to let the Emacs settings pass through.

And not to hard code it in Org.

To circumvent hard coding in Org, one can always use elisp: type of links:

(defun my-handler (mid)
 (message mid))

[[elisp:(my-handler "I am ok here")][my handler]]

Though it is not logical to hard code in Org how this or that URL
can't be open, as Org should allow present configuration of user to
run. Is that currentlyy working?

> Configuring of "mid:" links requires just a few lines in init.el and they
> are quite usual for custom links.

I have configured it, it does not work in Org

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 24/01/2023 01:37, Jean Louis wrote:
> 
> All URLs defined by Emacs that are to be run by browse-url in Org
> shall be allowed by org, to let the Emacs settings pass through.
> 
> And not to hard code it in Org.

It reminds be complains by some person that Org must be able to 
recognize any URL in free-form plain text just because there is a RFC 
describing format of URL.

Try to think from position of a developer.

An entry may be added to `browse-url-handlers' after loading of ol.

org-link and browse-url are so flexible that it would be hard to 
reliably match their entries taking into account different set of 
supported features. The former allows e.g. fuzzy search links, the 
latter something similar to Android deep links.

>> Configuring of "mid:" links requires just a few lines in init.el and they
>> are quite usual for custom links.
> 
> I have configured it, it does not work in Org

I have no idea which way you configured mid: links in Org, but this 
thread contains 5 lines that successfully works for me.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-24 20:25]:
> On 24/01/2023 01:37, Jean Louis wrote:
> > 
> > All URLs defined by Emacs that are to be run by browse-url in Org
> > shall be allowed by org, to let the Emacs settings pass through.
> > 
> > And not to hard code it in Org.
> 
> It reminds be complains by some person that Org must be able to recognize
> any URL in free-form plain text just because there is a RFC describing
> format of URL.

That person did not really propose to Org to do it, but to have Emacs
EWW to be customizable, so that any content type could be opened by
user's settings. You missed the point of it.

> Try to think from position of a developer.

From position of developer, developers shall ideally think of users,
and users think of the assistance of computer to users. 

Users appreciate developers who make their life easier.

> An entry may be added to `browse-url-handlers' after loading of ol.
> 
> org-link and browse-url are so flexible that it would be hard to reliably
> match their entries taking into account different set of supported features.
> The former allows e.g. fuzzy search links, the latter something similar to
> Android deep links.

That means Org authors missed to use Emacs built-ins. 

> I have no idea which way you configured mid: links in Org, but this thread
> contains 5 lines that successfully works for me.

When goto-mode works with mid: by me setting up browse-url-handlers,
then I have expected Org to work as well. 

But I do not rely on Org mode to use browse-url, rather I rely on Org
using elisp: links.

That is not really "mid:" but it will work for long time and be
independent of Org developers' decisions.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 25/01/2023 00:49, Jean Louis wrote:
> * Max Nikulin [2023-01-24 20:25]:
>> It reminds be complains by some person that Org must be able to recognize
>> any URL in free-form plain text just because there is a RFC describing
>> format of URL.
> 
> That person did not really propose to Org to do it, but to have Emacs
> EWW to be customizable, so that any content type could be opened by
> user's settings. You missed the point of it.

I had in mind another person:

Re: URLs with brackets not recognised. Wed, 12 May 2021 22:06:50 +0200.
> I disagree. URLs are well-specified. Per RFC 3986, the characters
> allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should
> implement proper URL detection, not asking its users "to give it some
> hints" and using "a kind of heuristics". A string either is a valid URL
> per the relevant RFCs or it is not.

You probably decided that I was writing about
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
[WISH]: Let us make EWW browse WWW Org files correctly

That is from my point of view is an excellent example how to bury a 
valid feature request "allow me to do" by aggressive demand "it must be 
by default" disregarding unresolved security issues and by adding more 
noise by discussion of unrelated stuff (should Org files have text/... 
or application/... mime type).

Back to the topic, URI handling packages have incompatible features. It 
is the reason why users have to had explicit configuration.

This is out of thread subject

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-25 18:33]:
> I had in mind another person:
> 
> Re: URLs with brackets not recognised. Wed, 12 May 2021 22:06:50 +0200.
> > I disagree. URLs are well-specified. Per RFC 3986, the characters
> > allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should
> > implement proper URL detection, not asking its users "to give it some
> > hints" and using "a kind of heuristics". A string either is a valid URL
> > per the relevant RFCs or it is not.
> 
> You probably decided that I was writing about
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
> [WISH]: Let us make EWW browse WWW Org files correctly
> 
> That is from my point of view is an excellent example how to bury a valid
> feature request "allow me to do" by aggressive demand "it must be by
> default" disregarding unresolved security issues and by adding more noise by
> discussion of unrelated stuff (should Org files have text/... or
> application/... mime type).
> 
> Back to the topic, URI handling packages have incompatible features. It is
> the reason why users have to had explicit configuration.

I can't follow or understand you in everything above.

Purpose of community discussions is to yield with something
productive. Whatever I said in the first notion does not need to be
so, and I really don't mind when I see that discussion deviated from
the point.

I am not Don Quixote to fight mills for browser that few people use
and have decision making. EWW still cannot support customizable
content/types but I also do not find it hard to bypass it's functions.

At least there was "useful" (by irony) decision that "opening Org
files in Emacs is security risk" -- one big fricking LOL on
that. Emacs itself is security risk, as it is programming language and
security is measured by weakest chain.

Haven thanks Firefox developers did not complain on users setting
their own content types. Firefox can open Org content type and launch
Emacs on it, but Emacs "can't" as it is security risk. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: This is out of thread subject

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> Haven thanks Firefox developers did not complain on users setting
> their own content types. Firefox can open Org content type and launch
> Emacs on it, but Emacs "can't" as it is security risk. 

Well...
https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
https://bugzilla.mozilla.org/show_bug.cgi?id=1565574

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: This is out of thread subject

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-25 21:01]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Haven thanks Firefox developers did not complain on users setting
> > their own content types. Firefox can open Org content type and launch
> > Emacs on it, but Emacs "can't" as it is security risk. 
> 
> Well...
> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994

That is fine, it is useful to be asked by which application something
will be opened. It is question about permission, which is given
once. That does not prevent user opening any URL with external
programs. Or content type.

There is more in computing than single user need. An HTML file on
local area network may list various URLs to various people of single
organization, and their work disconnected from Internet -- where all
users can access any kind of files, it need not be single user need.

> https://bugzilla.mozilla.org/show_bug.cgi?id=1565574

Any hyperlinks executing external program should not be opened
automatically of course. Imagine placing 20 various programs as
hyperlinks where user by opening single page launches 20 programs,
that is out of control of user. Having option for user to decide to
allow it, would be fine..

Otherwise hyperlinks like mid: should not be opened automatically,
hyperlink should wait for user to activate it.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: This is out of thread subject

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> Well...
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
>
> That is fine, it is useful to be asked by which application something
> will be opened. It is question about permission, which is given
> once. That does not prevent user opening any URL with external
> programs. Or content type.

Not once. The main problem raised in that bug report is that "always
allow" is unconditionally linked to current url, which is useless for
org-capture - the end result is Firefox asking permission almost every
single time.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Firefox permission dialog and org-protocol

[Max Nikulin]

On 26/01/2023 01:01, Ihor Radchenko wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994

Bug 1678994 "website permission to open special links in external 
applications not configurable"

Ihor, do you know any details concerning the affected add-on? It seems 
in LinkRemark I managed to avoid the issue somehow. Perhaps due to 
<all_urls> (Access your data for all websites) permission is required in 
the released version. Or I have specific handler for org-protocol, not 
"always ask" in Firefox configuration.

Re: Firefox permission dialog and org-protocol

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 26/01/2023 01:01, Ihor Radchenko wrote:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
>
> Bug 1678994 "website permission to open special links in external 
> applications not configurable"
>
> Ihor, do you know any details concerning the affected add-on? It seems 
> in LinkRemark I managed to avoid the issue somehow. Perhaps due to 
> <all_urls> (Access your data for all websites) permission is required in 
> the released version. Or I have specific handler for org-protocol, not 
> "always ask" in Firefox configuration.

It appears to be a newer version of Firefox.
I originally got to know about the problem from
https://old.reddit.com/r/emacs/comments/10jr2up/orgprotocol_permissions_on_firefox/

We may ask further details from the user if necessary.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Firefox permission dialog and org-protocol

[Max Nikulin]

On 29/01/2023 20:50, Ihor Radchenko wrote:
> Max Nikulin writes:
>> On 26/01/2023 01:01, Ihor Radchenko wrote:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
>>
>> Bug 1678994 "website permission to open special links in external
>> applications not configurable"
...
> It appears to be a newer version of Firefox.
> I originally got to know about the problem from
> https://old.reddit.com/r/emacs/comments/10jr2up/orgprotocol_permissions_on_firefox/

Likely the person uses a bookmarklet to initiate capture. This case 
JavaScript snippet is executed in the context of the current web site, 
so it is necessary to confirm permission for each site. I would 
recommend to install an add-on for org-protocol instead. It would be 
enough to confirm once that *this extension* is allowed to launch 
external application through a custom scheme URI.

An additional advantage is that if some site were had a malicious 
org-protocol link hidden by some attractive description then browser 
would ask user even if some pages on the same site were captured earlier.

I faced a similar issue 3 years ago when "always allow" checkbox just 
disappeared from chromium popup.

The popup with permission request appeared because some version of zoom 
allowed unsolicited video call. They decided that a dialog in the app 
before switching on camera would be annoying to users. Users already 
confirmed their intention in the Safari dialog. So other browser had to 
add this popup as well. The intention is to avoid joining a video call 
accidentally while being naked.

https://infosecwriteups.com/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5?gi=2ed4ab044837
Jonathan Leitschuh. Zoom Zero Day: 4+ Million Webcams & maybe an RCE? 
Just get them to visit your website! 2019-07-08

To summarize, I believe that a browser extension is a safer way to use 
org-protocol. With a native messaging helper application it is even 
possible to avoid desktop-wide org-protocol configuration and to call 
emacsclient directly by the add-on but not through links on non-trusted 
web sites.

P.S. Actually launching an application from an add-on is not really 
reliable as well. The following issue has links to some other bugs. Not 
to mention that external scheme URI is a shoot and forget approach with 
hardly possible error detection. (A native host application may check 
emacsclient exit code.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1745931
External scheme handler configured to "Always ask" can not be launched 
from add-on background page.

[BUG] org-manual: Using bookmarklet for org-capture is no longer reliable (was: Firefox permission dialog and org-protocol)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

 To summarize, I believe that a browser extension is a safer way to use 
> org-protocol. With a native messaging helper application it is even 
> possible to avoid desktop-wide org-protocol configuration and to call 
> emacsclient directly by the add-on but not through links on non-trusted 
> web sites.

This is bad news.

17.16.2 The ‘capture’ protocol section of Org manual recommends

       To use this feature, add a bookmark with an arbitrary name, e.g.,
    ‘Org: capture’, and enter this as ‘Location’:
    
         javascript:location.href='org-protocol://capture?' +
               new URLSearchParams({
                     template: 'x', url: window.location.href,
                     title: document.title, body: window.getSelection()});

With the annoying Firefox dialogue, things get very annoying.
Even though I do understand the motivation of devs.
But they broke bookmarklets :'(

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Charles Philip Chan]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

>>>>> "Ihor" == Ihor Radchenko <yantar92@posteo.net> writes:

Hi  Ihor,

    Ihor> This is bad news.

    Ihor> 17.16.2 The ‘capture’ protocol section of Org manual recommends

    Ihor> To use this feature, add a bookmark with an arbitrary name, e.g.,
    Ihor> ‘Org: capture’, and enter this as ‘Location’:
    
    Ihor> javascript:location.href='org-protocol://capture?' + new
    Ihor> URLSearchParams({ template: 'x', url: window.location.href, title:
    Ihor> document.title, body: window.getSelection()});

    Ihor> With the annoying Firefox dialogue, things get very annoying.  Even
    Ihor> though I do understand the motivation of devs.  But they broke
    Ihor> bookmarklets :'(

I have been using this org-protocol addon[1] for more than a year and it has
been rock solid for me. According to the author, bookmarklets are getting less
and less useful because CSP (Content Security Policy) blocking them on many
sites (for example Github)[2].

Charles

Footnotes:
[1] https://addons.mozilla.org/en-US/firefox/addon/org-protocol/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search

[2]  https://github.com/vifon/org-protocol-for-firefox



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 219 bytes --]

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Max Nikulin]

On 31/01/2023 15:11, Charles Philip Chan wrote:
> I have been using this org-protocol addon[1] for more than a year and it has
> been rock solid for me. According to the author, bookmarklets are getting less
> and less useful because CSP (Content Security Policy) blocking them on many
> sites (for example Github)[2].

Thank you for the reminder. Using an add-on to extract metadata, I have 
never tried if bookmarklets are affected by CSP.

I think, we assume different definitions of "rock solid". Does it able 
to detect that desktop configuration of org-protocol is broken and to 
notify the user about failure? I do not use :immediate-finish templates, 
but some people do. There is a risk to quietly lost captures. I do not 
see other ways to detect errors besides a native messaging helper 
application.

(info "(org) Template elements") 
https://orgmode.org/manual/Template-elements.html

> [2]  https://github.com/vifon/org-protocol-for-firefox

This extension uses browser.tabs.update method to launch external 
protocol handler. Perhaps in some cases it is better than assigning 
window.location.href from a content script like in older

https://github.com/sprig/org-capture-extension/

however I have seen issues with both methods. It is a grey zone and it 
is hard to predict which one will be more reliable in next versions of 
browsers. Actually some people believe that even mailto: was a hack, it 
is not a resource identifier as it can be expected from URI

https://github.com/w3c/web-share/blob/main/docs/explainer.md#why-not-make-a-share-uri-scheme-like-mailto-instead-of-a-javascript-api
https://github.com/chromium/ballista/issues/21
Expand on why registerProtocolHandler and registerProtocolHandler are a hack
> The question I have to ask myself, though, is if we were designing
> mailto: today, would we do it the same way? And I think the answer is
> "no, mailto: is and always was a hack, because we didn't have JavaScript".

So we should not expect that org-protocol: will work reliably in 
browsers. Position of a firefox developers concerning external handlers 
for custom protocols:

Bug 1744018 - External scheme handler launched by an add-on can be 
blocked despite user action
https://bugzilla.mozilla.org/show_bug.cgi?id=1744018#c16
> Pairing the extension with a native application and use the
> nativeMessaging API seems a better fit for the use case you are describing

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> I think, we assume different definitions of "rock solid". Does it able 
> to detect that desktop configuration of org-protocol is broken and to 
> notify the user about failure? I do not use :immediate-finish templates, 
> but some people do. There is a risk to quietly lost captures. I do not 
> see other ways to detect errors besides a native messaging helper 
> application.
>
> (info "(org) Template elements") 
> https://orgmode.org/manual/Template-elements.html

Would it be reasonable to make org-protocol raise Emacs frame on
failure?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Max Nikulin]

On 01/02/2023 20:38, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> I think, we assume different definitions of "rock solid". Does it able
>> to detect that desktop configuration of org-protocol is broken and to
>> notify the user about failure? I do not use :immediate-finish templates,
>> but some people do. There is a risk to quietly lost captures. I do not
>> see other ways to detect errors besides a native messaging helper
>> application.
> 
> Would it be reasonable to make org-protocol raise Emacs frame on
> failure?

Raising frame may help if window manager allows to do it. In some cases 
the only possibility for a window is to request attention. Creating new 
frame may be more reliable. Window manager may still take measures 
against focus stealing. I have heard that such feature exist, but I am 
unsure concerning severity of such policy.

However I was writing a more annoying issue. Firefox may quietly swallow 
attempt to launch external protocol handler. Even no message is spitted 
to console like in the case of unknown protocol or throttling due to 
multiple attempts during short interval of time. Emacs is completely 
unaware of capture attempt in such case.

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Would it be reasonable to make org-protocol raise Emacs frame on
>> failure?
>
> Raising frame may help if window manager allows to do it. In some cases 
> the only possibility for a window is to request attention. Creating new 
> frame may be more reliable. Window manager may still take measures 
> against focus stealing. I have heard that such feature exist, but I am 
> unsure concerning severity of such policy.

That's usually up to user.

> However I was writing a more annoying issue. Firefox may quietly swallow 
> attempt to launch external protocol handler. Even no message is spitted 
> to console like in the case of unknown protocol or throttling due to 
> multiple attempts during short interval of time. Emacs is completely 
> unaware of capture attempt in such case.

Can Firefox extensions use DBUS?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Max Nikulin]

On 02/02/2023 21:17, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>>> Would it be reasonable to make org-protocol raise Emacs frame on
>>> failure?
>>
>> Raising frame may help if window manager allows to do it. In some cases
>> the only possibility for a window is to request attention. Creating new
>> frame may be more reliable. Window manager may still take measures
>> against focus stealing. I have heard that such feature exist, but I am
>> unsure concerning severity of such policy.
> 
> That's usually up to user.

I would not be so sure for windows. Even on Linux Org should be ready 
for any user configuration of window manager.

>> However I was writing a more annoying issue. Firefox may quietly swallow
>> attempt to launch external protocol handler. Even no message is spitted
>> to console like in the case of unknown protocol or throttling due to
>> multiple attempts during short interval of time. Emacs is completely
>> unaware of capture attempt in such case.
> 
> Can Firefox extensions use DBUS?

Browser extensions are isolated as much as possible. It is assumed that 
they communicate with web sites. They may communicate with a native 
messaging application however. It must be installed and configured in 
addition to the extension. This native host application may use D-BUS, 
but it may invoke emacsclient directly. E.g. I use 
https://github.com/maxnikulin/linkremark extension with 
https://github.com/maxnikulin/burl native messaging helper.

I have not checked state of affairs recently, but when I tried native 
messaging applications were unavailable for browsers shipped as snap or 
flatpack packages (due to additional level of isolation). At least some 
related Firefox bugs have not closed yet.

So in practice it is possible to get it working in both cases: external 
protocol handlers and native messaging helper. I would call any approach 
"rock solid" currently.

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Max Nikulin]

On 31/01/2023 15:11, Charles Philip Chan wrote:
> According to the author, bookmarklets are getting less
> and less useful because CSP (Content Security Policy) blocking them on many
> sites (for example Github)[2].
> [2]  https://github.com/vifon/org-protocol-for-firefox

Have you experienced the issue with simple bookmarklets, similar to ones 
suggested in the Org manual, after the following fix?

https://bugzilla.mozilla.org/show_bug.cgi?id=1478037
Bug 1478037 Allow bookmarklets to run even when the CSP on the page 
would normally block javascript: execution
Fixed in Firefox-69 2019-05-31 14:56 PDT

If I understand it correctly, the problem persists with bookmarklets 
injecting 3rd party scripts into current page, see

https://bugzilla.mozilla.org/show_bug.cgi?id=866522
Bug 866522 Bookmarklets affected by CSP

So the popup to confirm launching external protocol handler may be 
considered annoying, but bookmarklets are not really broken. An add-on 
may improve user experience.

Likely mentioning browser extensions in the manual is the way to fix 
this bug in the scope of Org. Unsure if a link to 
https://chrome.google.com/webstore/ may be considered as promoting of 
non-free software (Google Chrome) by a GNU project.

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> Likely mentioning browser extensions in the manual is the way to fix 
> this bug in the scope of Org. Unsure if a link to 
> https://chrome.google.com/webstore/ may be considered as promoting of 
> non-free software (Google Chrome) by a GNU project.

It does not promote Google Chrome per se. Chromium does exist under BSD
licence.

And we do not need to link to web sore. May as well just mention that
many extensions exist for popular browsers.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Firefox permission dialog and org-protocol

[Samuel Wales]

unable to follow this but it sounds like a big deal and i am glad that
you are looking into it.  thanks.

[my use case fwiw:
1] it is disruptive for me having org-capture not work [i do not alwys use kb].
2] x-wide capture using emacsclient would presumably not contain the
page title in firefox.
3] if automatic reliable confirmation if possible results as a side
effect of this work, great.
4] oh do i ever want advanced spookfox!
please ignore all of this just want to say thanks.]


On 1/29/23, Max Nikulin <manikulin@gmail.com> wrote:
> On 29/01/2023 20:50, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>> On 26/01/2023 01:01, Ihor Radchenko wrote:
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
>>>
>>> Bug 1678994 "website permission to open special links in external
>>> applications not configurable"
> ...
>> It appears to be a newer version of Firefox.
>> I originally got to know about the problem from
>> https://old.reddit.com/r/emacs/comments/10jr2up/orgprotocol_permissions_on_firefox/
>
> Likely the person uses a bookmarklet to initiate capture. This case
> JavaScript snippet is executed in the context of the current web site,
> so it is necessary to confirm permission for each site. I would
> recommend to install an add-on for org-protocol instead. It would be
> enough to confirm once that *this extension* is allowed to launch
> external application through a custom scheme URI.
>
> An additional advantage is that if some site were had a malicious
> org-protocol link hidden by some attractive description then browser
> would ask user even if some pages on the same site were captured earlier.
>
> I faced a similar issue 3 years ago when "always allow" checkbox just
> disappeared from chromium popup.
>
> The popup with permission request appeared because some version of zoom
> allowed unsolicited video call. They decided that a dialog in the app
> before switching on camera would be annoying to users. Users already
> confirmed their intention in the Safari dialog. So other browser had to
> add this popup as well. The intention is to avoid joining a video call
> accidentally while being naked.
>
> https://infosecwriteups.com/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5?gi=2ed4ab044837
> Jonathan Leitschuh. Zoom Zero Day: 4+ Million Webcams & maybe an RCE?
> Just get them to visit your website! 2019-07-08
>
> To summarize, I believe that a browser extension is a safer way to use
> org-protocol. With a native messaging helper application it is even
> possible to avoid desktop-wide org-protocol configuration and to call
> emacsclient directly by the add-on but not through links on non-trusted
> web sites.
>
> P.S. Actually launching an application from an add-on is not really
> reliable as well. The following issue has links to some other bugs. Not
> to mention that external scheme URI is a shoot and forget approach with
> hardly possible error detection. (A native host application may check
> emacsclient exit code.)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1745931
> External scheme handler configured to "Always ask" can not be launched
> from add-on background page.
>
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 25/01/2023 00:49, Jean Louis wrote:
> When goto-mode works with mid: by me setting up browse-url-handlers,
> then I have expected Org to work as well.

Do you mean `goto-address-mode'? Have you had a look into its 
implementation?

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-26 19:21]:
> On 25/01/2023 00:49, Jean Louis wrote:
> > When goto-mode works with mid: by me setting up browse-url-handlers,
> > then I have expected Org to work as well.
> 
> Do you mean `goto-address-mode'? Have you had a look into its
> implementation?

I have already previously mentioned about it. 

In my opinion, features such as opening specific function on URI
scheme shall be unified in Emacs.

Org should now hard code new way of opening URL schemes, but use Emacs
settings.

And I am aware that it is late for such decision, historical decision
was individual based, when Org was not part of Emacs, and it will
break compatibility but then you could introduce option for people to
start changing slowly and integrating better with whole system.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 27/01/2023 13:41, Jean Louis wrote:
> * Max Nikulin [2023-01-26 19:21]:
>> On 25/01/2023 00:49, Jean Louis wrote:
>>> When goto-mode works with mid: by me setting up browse-url-handlers,
>>> then I have expected Org to work as well.
>>
>> Do you mean `goto-address-mode'? Have you had a look into its
>> implementation?
> 
> I have already previously mentioned about it.

I was unsure if goto-mode is a typo or some 3rd party package. Have you 
written that you are aware which way it is implemented?

List of recognized protocols is not a user option, it is hard-coded and 
unrelated to the browse-url-handlers:

defvar thing-at-point-uri-schemes

the list is rather long.

On 25/01/2023 00:49, Jean Louis wrote:
>> Try to think from position of a developer.
> 
> From position of developer, developers shall ideally think of users,
> and users think of the assistance of computer to users. 
> 
> Users appreciate developers who make their life easier.

Developer must consider other features that may be affected by demanded 
changes. False positives are acceptable for thingatpt and 
goto-address-mode. For Org mode balance is different. Too greedy regexp 
to recognize links may have detrimental effect on export and publish, 
not to mention that links may need special treatment. In addition Ihor 
mentioned fuzzy links.

On 27/01/2023 13:41, Jean Louis wrote:
> In my opinion, features such as opening specific function on URI
> scheme shall be unified in Emacs.

Generally agree, but browse-url should be ready to reuse its 
configuration in Org. I am afraid, it means less flexible browse-url.

> Org should now hard code new way of opening URL schemes, but use Emacs
> settings.

Try to derive list of supported schemes from `browse-url-handlers'.

> And I am aware that it is late for such decision,

You may try to talk to `browse-url' developers if they are ready to make 
their package less flexible for the sake of Org mode.

And finally notice that goto-address-mode is unable to properly handle

     (test https://orgmode.org)

it considers closing parenthesis as a part of the link. In addition 
there are disclaimers:

     Customizations to this variable made after goto-addr is loaded
     will have no effect.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-27 18:22]:
> I was unsure if goto-mode is a typo or some 3rd party package. Have
> you written that you are aware which way it is implemented?

I am aware of inconsistencies, and I wish Emacs would have it
centralized.

> List of recognized protocols is not a user option, it is hard-coded
> and unrelated to the browse-url-handlers:
> 
> defvar thing-at-point-uri-schemes
> 
> the list is rather long.

Yes, there are official, unofficial, and just that it is not user
option means nothing much, I am adding to that list what I wish by
using `add-to-list' function, as just as `load-path' variable cannot
be customized with "customize", it can still be changed with
`add-to-list'.

> Developer must consider other features that may be affected by demanded
> changes. False positives are acceptable for thingatpt and goto-address-mode.
> For Org mode balance is different. Too greedy regexp to recognize links may
> have detrimental effect on export and publish, not to mention that links may
> need special treatment. In addition Ihor mentioned fuzzy links.

I got it.

How I understand it, Org should be more deterministic and for that
can't use other available libraries.

> > Org should now hard code new way of opening URL schemes, but use Emacs
> > settings.
> 
> Try to derive list of supported schemes from `browse-url-handlers'.

browse-url-handlers ➜ (("gemini:" . elpher-go) ("gopher:"
. elpher-handler-go) ("about:" . hyperscope-about) ("hyperscope:"
. hyperscope-url) ("e2dk://" . amule-handler))

it is user option to be customized.

It is obvious that my idea that URL schemes should be unified may be
reasonable, but there is not enough programming functionality in Emacs
to allow it to be very deterministic. And thus Org has to make it's
own URL handling. That is how I understand, correct me if this is
wrong.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> Try to derive list of supported schemes from `browse-url-handlers'.
>
> browse-url-handlers ➜ (("gemini:" . elpher-go) ("gopher:"
> . elpher-handler-go) ("about:" . hyperscope-about) ("hyperscope:"
> . hyperscope-url) ("e2dk://" . amule-handler))
>
> it is user option to be customized.
>
> It is obvious that my idea that URL schemes should be unified may be
> reasonable, but there is not enough programming functionality in Emacs
> to allow it to be very deterministic. And thus Org has to make it's
> own URL handling. That is how I understand, correct me if this is
> wrong.

Kind of. `browse-url-handlers' may have predicate as a function. Then,
or may need to run all the predicates any time we need to know if given
url-looking string is a link or not and what type of link. Considering
that such information is needed, among other times, during
fontification, I doubt that we can practically support
`browse-url-handlers'. Or we can make Org unusable.

`browse-url-handlers' is designed in a way that is to be used on demand
only - when the user issues an interactive command.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Jean Louis <bugs@gnu.support> writes:

> And not to hard code it in Org.
>
> To circumvent hard coding in Org, one can always use elisp: type of links:
>
> (defun my-handler (mid)
>  (message mid))
>
> [[elisp:(my-handler "I am ok here")][my handler]]

Org also allows the user to define his own link types:

 (info "(org) Adding Hyperlink Types")


Bruno

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Bruno Barbier <brubar.cs@gmail.com> [2023-01-24 20:31]:
> > [[elisp:(my-handler "I am ok here")][my handler]]
> 
> Org also allows the user to define his own link types:
> 
>  (info "(org) Adding Hyperlink Types")

I understand. 

You see, Org is part of Emacs, me I expect that when I follow Emacs
Instructions that Org will be using Emacs settings, but it follows
it's own settings.

I mean these settings:

browse-url-handlers is a variable defined in ‘browse-url.el’.

Its value is
(("gemini:" . elpher-go)
 ("gopher:" . elpher-handler-go)
 ("about:" . hyperscope-about)
 ("mid:" . my-handler)
 ("hyperscope:" . hyperscope-url)
 ("e2dk://" . amule-handler))
Original value was nil

An alist with elements of the form (REGEXP-OR-PREDICATE . HANDLER).
Each REGEXP-OR-PREDICATE is matched against the URL to be opened
in turn and the first match’s HANDLER is invoked with the URL.

A HANDLER must be a function with the same arguments as
‘browse-url’.

If no REGEXP-OR-PREDICATE matches, the same procedure is
performed with the value of ‘browse-url-default-handlers’.  If
there is also no match, the URL is opened using the value of
‘browse-url-browser-function’.

  This variable was introduced, or its default value was changed, in
  version 28.1 of Emacs.
  You can customize this variable.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

[FR] Should Org provide commonly used link types? (was: Link from orgmode file to E-Mail (using kmail or notmuch))

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> You see, Org is part of Emacs, me I expect that when I follow Emacs
> Instructions that Org will be using Emacs settings, but it follows
> it's own settings.
>
> I mean these settings:
>
> browse-url-handlers is a variable defined in ‘browse-url.el’.
>
> Its value is
> (("gemini:" . elpher-go)
>  ("gopher:" . elpher-handler-go)
>  ("about:" . hyperscope-about)
>  ("mid:" . my-handler)
>  ("hyperscope:" . hyperscope-url)
>  ("e2dk://" . amule-handler))
> Original value was nil

I do not mind adding several useful link protocols. But which ones?

Org cannot just treat arbitrary [[foo:bar]] as links because it will
break internal link references like

[[ref:one]]
<<ref:one>>

So, we cannot just say: use `browse-url' when the link type is known.
The link types in Org are a closed list.

What we can do is add some more known link types. Some of them will use
`browse-url' as :follow link parameter.

However, what are the link types which are worth including into the Org
code? I am looking into the protocols supported by Firefox now.
They are: mailto, news, nntp, snwes, afp, data, disk, disks, hcp, htp,
htps, http, iehistory, ierss, ile, javascript, le, mk, moz-icon,
ms-help, ms-msdt, ps, res, search, search-ms, shell, tps, ttp, ttps,
vbscript, vnd.ms.radio, and file.

Note that mid: is not listed.

Suggestions welcome. Probably, we can at least support the protocols
available via Emacs packages (e.g. notmuch does support mid: links).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Should Org provide commonly used link types?

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-25 15:56]:
> What we can do is add some more known link types. Some of them will use
> `browse-url' as :follow link parameter.
> 
> However, what are the link types which are worth including into the Org
> code? I am looking into the protocols supported by Firefox now.
> They are: mailto, news, nntp, snwes, afp, data, disk, disks, hcp, htp,
> htps, http, iehistory, ierss, ile, javascript, le, mk, moz-icon,
> ms-help, ms-msdt, ps, res, search, search-ms, shell, tps, ttp, ttps,
> vbscript, vnd.ms.radio, and file.

It is not relevant what Firefox support or not, as it is user
customizable option.

> Note that mid: is not listed.

User can set it.

> Suggestions welcome

Main suggestion would be to make interface for users to easy setup
those hyperlinks.

If user is supposed to adapt mind to programmer by setting this horror:
(info "(org) Adding Hyperlink Types")
that leads nowhere. Forget about "usability".

Customize interface is much better.

How about this in customize?

- prefix: pdf
- format %s&%s
- function to run: open-pdf

However, how it was programmed in Org in such demanding and boring
way. No wonder people complain for simple PDF opening by page number.

I am changing my mind, now I really think that it is better you hard
code those hyperlinks in Org as you said, that way you will get
functionality that users can still choose but need not be bothered by
programming.

1. For PDF there are not many PDF viewers that support opening by page
   number or query, so you could hard code it all. XPDF is so far best
   as it supports capturing in easy manner.

2. For mpv, vlc, you can open video and audio hyperlinks at specific
   place. I am using `mpv' package to capture video at exact point like this:

(defun hyperscope-capture-mpv-playback-position ()
  (interactive)
  (cond ((mpv-live-p)
	 (mpv-pause)
	 (let ((time (mpv-get-playback-position))
	       ;; subtype?
	       (name (rcd-ask-get "Name video position: ")))
	   (cond (time (hyperscope-add-generic name hyperscope-mpv-played-video nil 3 nil 1 time))
		 (t (rcd-warning-message "Could not get time for video play"))))
	 (mpv-pause))
	(t (rcd-warning-message "mpv not running"))))

which is very easy to convert to Org. Package `mpv' already supports
Org type Hyperlinks.

Summary for now, PDF, video, audio, plus all at exact location.

What about EPUB, DJVU, MOBI? 

- mupdf supports opening EPUB at specific page
- zathura will surely work with DJVU to open at specific page

Summary: PDF, EPUB, DJVU, video, audio, plus all at exact location.

I am using general "media" which can be either audio, or video, could be PDF or something else.

Message-ID, should support FOLDER+Message-ID

Is it possible to support Emacs bookmarks as hyperlinks? I would
include that.

xournalapp is software that I use, and RMS uses too I heard, it is
excellent for PDF editing. It has its own format and can open up also
by page number.

Geo location shall be supported, as it has already many handlers in
GNU/Linux, then GPX files, GeoJSON files

I have playlists as hyperlink, and other 100 different examples which
I do not consider immediately useful for Org.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Should Org provide commonly used link types?

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> Suggestions welcome
>
> Main suggestion would be to make interface for users to easy setup
> those hyperlinks.
>
> If user is supposed to adapt mind to programmer by setting this horror:
> (info "(org) Adding Hyperlink Types")
> that leads nowhere. Forget about "usability".

I am sorry, but what can be simpler than

     (org-link-set-parameters "man" :follow #'org-man-open)

?

At least, when we only consider Elisp interface.

> Customize interface is much better.
>
> How about this in customize?
>
> - prefix: pdf
> - format %s&%s
> - function to run: open-pdf

org-link-parameters

We can improve custom type definition there, but otherwise we do provide
customize interface.

> I am changing my mind, now I really think that it is better you hard
> code those hyperlinks in Org as you said, that way you will get
> functionality that users can still choose but need not be bothered by
> programming.
> ...

[ Some of the suggestions have been discussed in the past - we do not
  oppose including more built-in link types. Patches are welcome. ]

So, the suggested links are:
1. pdf + page
2. video/audio + timestamp
3. epub/djvu/mibi + page

Note that all these are basically file: links. While we can make users
say pdf:... or video:..., or would be more convenient to extend file:
link instead. Max pointed to experimental proof-of-concept code for pdf
+ page in another email.

> Message-ID, should support FOLDER+Message-ID

I am not sure here. How can we utilize FOLDER? It depend on the kind of
external application or Emacs package we use to open the link.

> Is it possible to support Emacs bookmarks as hyperlinks? I would
> include that.

There is ol-bookmarks package distributed as a part of org-contrib.
Someone with copyright assignment may take a look and re-implement it.

> Geo location shall be supported, as it has already many handlers in
> GNU/Linux, then GPX files, GeoJSON files

Are there any? I only know web handlers. I did search at some point.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should Org provide commonly used link types?

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-25 21:15]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> Suggestions welcome
> >
> > Main suggestion would be to make interface for users to easy setup
> > those hyperlinks.
> >
> > If user is supposed to adapt mind to programmer by setting this horror:
> > (info "(org) Adding Hyperlink Types")
> > that leads nowhere. Forget about "usability".
> 
> I am sorry, but what can be simpler than
> 
>      (org-link-set-parameters "man" :follow #'org-man-open)

Customize is simpler, it was made to help users, that is what we have in Emacs:

Hyperlink URI scheme: man
Function: org-man-open


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Should Org provide commonly used link types?

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-25 21:15]:
> So, the suggested links are:
> 1. pdf + page
> 2. video/audio + timestamp
> 3. epub/djvu/mibi + page
> 
> Note that all these are basically file: links. While we can make users
> say pdf:... or video:..., or would be more convenient to extend file:
> link instead. Max pointed to experimental proof-of-concept code for pdf
> + page in another email.

Yes, you could extend file: and make special handlings for various types.

> > Message-ID, should support FOLDER+Message-ID
> 
> I am not sure here. How can we utilize FOLDER? It depend on the kind of
> external application or Emacs package we use to open the link.

If you only provide "mid" and function for user to customize it, that
is enough, then user's function must know how to handle it.

However, that is not by standard as "mid:" is not meant to be
referable from Org. See: https://www.rfc-editor.org/rfc/rfc2392

That URL expects message-id only, with possible content-id

     mid-url       = "mid" ":" message-id [ "/" content-id ]

Which means, in turn, that "mid:" shall be reserved only for indexing
programs, as RFC mentions "indexed", and I assume that is what was
meant with it.

Many e-mail clients do not have general indexing of e-mails and yet
they internally use Message IDs and have no problems finding it, or
may have internal indexing not exposed to user.

I do think that my proposal is more flexible, by allowing user to
introduce function, user can go away from standard and introduce
folder, in the sense:

mid:/home/user/Maildir?1231212@gnu.org

with parts being:

mid	:	/home/user/Maildir	?	1231212@gnu.org

I have many many mbox files on computer, they are used by various
programs, there is no single program opening all of mbox-es, and
Maildirs, and I have 59869+ Maildirs in total.

In case I as user change e-mail client to some indexing one, my
function can still discard the file location part and find Message ID

Another idea is to use "file:" as usual, for those e-mail Message IDs
which are stored in files, in that case function again must be
somewhere to detect:

- if file is Maildir, mbox
- to use Page ID part of "file:" if such exist, as Message-ID

or third, new URI scheme can be introduced, such as "message-id:"
which supports file and message ID together.

Outside of scope of thread:
---------------------------

Personally I have it solved with hyperlinks on higher level, they
remain immutable inside of Org, while decision making how to open them
is decided in their definition.

[[elisp:(hyperscope-action 1)][📝 ╔ Notes]]

[[elisp:(hyperscope 73361)][Secondary School in Lobolwala]]

And there is even more general UUID based hyperlink:

[[elisp:(uuid "6ADD037A-31BC-435A-BEC8-FE990EBF2A17")][Secondary School in Lobolwala]]

UUID based hyperlinks avoid hard coding hyperlink, and avoid hard
coding the action to run hyperlink.

Actions for UUID are then defined by user. When capturing UUID
hyperlink, name is captured as well to construct Org hyperlink.

(defcustom rcd-db-uuid-action-alist '(("people" . cf-people-by-id)
				      ("hyobjects" . hyperscope)
				      ("sobjects" . ignore)
				      ("predicates" . ignore)
				      ("uuid2uuid" . ignore)
				      ("properties" . rcd-notes-properties-list-by-referenced-uuid)
				      ("statsdefinitions" . rcd-r-statistics-view)
				      ("transactions" . rcd-accounts-transaction-edit)
				      ("messages" . rcd-message-edit))
  "Database UUID action alist."
  :group 'rcd
  :type '(alist))

That way using abstract UUID hyperlinks enables more flexibility,
practically more collaboration and accessibility to hyperlinks, as it
does not "hard code" the object named "Joe Doe", as that object may go
across computers. "Joe Doe" vCard may be opened on computer A, if such
has been received, because it has same UUID inside, while on computer
B, database entry is opened locally for that UUID, but on computer C,
remote database entry is accessed.

> > Geo location shall be supported, as it has already many handlers in
> > GNU/Linux, then GPX files, GeoJSON files
> 
> Are there any? I only know web handlers. I did search at some point.

When you use geographic software, the /usr/share/applications get
populated with various handlers, for example:

  -rw-r--r-- 1 1.2K Jan 11 20:53 marble_geo.desktop
with Exec=marble --geo-uri=%u

Yes, there are many web based handlers.

In Emacs there is `osm' package that can easily use Openstreetmaps as
URI handler for "geo:"

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Should Org provide commonly used link types?

[jawatech]

Jean Louis 於 2023/1/26 上午 12:40 寫道:
> * Ihor Radchenko <yantar92@posteo.net> [2023-01-25 15:56]:
>> What we can do is add some more known link types. Some of them will use
>> `browse-url' as :follow link parameter.
>>
>> However, what are the link types which are worth including into the Org
>> code? I am looking into the protocols supported by Firefox now.
>> They are: mailto, news, nntp, snwes, afp, data, disk, disks, hcp, htp,
>> htps, http, iehistory, ierss, ile, javascript, le, mk, moz-icon,
>> ms-help, ms-msdt, ps, res, search, search-ms, shell, tps, ttp, ttps,
>> vbscript, vnd.ms.radio, and file.
> 
> 
> Summary: PDF, EPUB, DJVU, video, audio, plus all at exact location.
> 
I've uploaded my solution to https://github.com/jawatech/obafgkm which 
might interest you. Some highlights:

- Open PDF.js & ePub viewer in Electron

- Using ipc to communicate within electron between main / renderer threads

- Using http server to receive commands issued from emacs that controls 
pdf.js

- org-add-link-type is used to implement customized link type

Any comments are welcome.

Hope this helps.

jawatech

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 23/01/2023 17:40, Ihor Radchenko wrote:
>> I am not even sure if we need to make Org open mid: links via
>> `browse-url'. Maybe it should be something else? IDK.
>
> Do you know an alternative? Org already uses this package to open some 
> types of links. It allows to have the same handler for all Emacs 
> packages. I do not think that Org-specific handler would be better.

I am mostly concerned that channelling mid: links to browse-url will not
work (open empty page in browser) in most cases. This is more confusing
than not having mid: link handler at all.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 24/01/2023 16:42, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> On 23/01/2023 17:40, Ihor Radchenko wrote:
>>> I am not even sure if we need to make Org open mid: links via
>>> `browse-url'. Maybe it should be something else? IDK.
>>
>> Do you know an alternative?
...
> I am mostly concerned that channelling mid: links to browse-url will not
> work (open empty page in browser) in most cases. This is more confusing
> than not having mid: link handler at all.

For me it may be a reason to not enable to enable "mid:" links by 
default, but I am still considering `browse-url' as the proper handler.

Code to determine handler is platform-specific, e.g. for Linux

xdg-mime query default x-scheme-handler/mid
xdg-settings get default-url-scheme-handler mid

The latter actually calls the former. I would avoid both variants during 
load time.

If you get browser fallback then you are advanced enough user to avoid a 
DE. Gnome shows application selection dialog, KDE throws an error window.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-24 18:52]:
> > I am mostly concerned that channelling mid: links to browse-url will not
> > work (open empty page in browser) in most cases. This is more confusing
> > than not having mid: link handler at all.
> 
> For me it may be a reason to not enable to enable "mid:" links by default,
> but I am still considering `browse-url' as the proper handler.

You should neither enable, neither disable opening of any links on the
Org level except maybe Emacs Lisp links.

Otherwise let users enable or disable what they want.

> Code to determine handler is platform-specific, e.g. for Linux
> 
> xdg-mime query default x-scheme-handler/mid
> xdg-settings get default-url-scheme-handler mid
> 
> The latter actually calls the former. I would avoid both variants during
> load time.
> 
> If you get browser fallback then you are advanced enough user to avoid a DE.
> Gnome shows application selection dialog, KDE throws an error
> window.

Let users open Hyperlinks with any browser or function how they want.

I am aware that Org has that mixed hyperlink types as explained in:

(info "(org) External Links") 

and when I say "mixed" it does not support the expected standard of
URI Schemes (https://en.wikipedia.org/wiki/List_of_URI_schemes) as it
introduces various Org related hyperlinks.

At this point, after so many years, nobody recognizes that such
capricious single user decision does not scale well for broad public.

And now because all the users are entangled using non-standard URI
schemes, it is very hard to switch, as it would break compatibility.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-24 12:43]:
> Max Nikulin <manikulin@gmail.com> writes:
> 
> > On 23/01/2023 17:40, Ihor Radchenko wrote:
> >> I am not even sure if we need to make Org open mid: links via
> >> `browse-url'. Maybe it should be something else? IDK.
> >
> > Do you know an alternative? Org already uses this package to open some 
> > types of links. It allows to have the same handler for all Emacs 
> > packages. I do not think that Org-specific handler would be better.
> 
> I am mostly concerned that channelling mid: links to browse-url will not
> work (open empty page in browser) in most cases. This is more confusing
> than not having mid: link handler at all.

Thanks.

It does not mean that browse-url "will not work" but that user did not
customize content types.

You need not think what users will customize neither you can't know what future brings.

Do you see that any browser could have the same strategy to maybe
forbid various URLs, but browsers mostly adopted the strategy to let
user customize how to open some URL.

From Org side that is all, you do not hard code how to open various
links, but there shall be customization for users to decide how to
open content types.

That is what other browsers do as well.

You don't need to think of it, as you cannot control other program
from Org. 

Please allow users to set URL handlers how they want. That is
customary for decades.

Other program must know how to handle hyperlinks, if to report error,
or to warn user or to ask user how to open such URLs.

For example Elinks with

$ elinks mid:123

"This URL contains a protocol not yet known by ELinks. You can
configure an external handler for it through the options system."

or for example Firefox:

"Firefox doesn’t know how to open this address, because one of the
following protocols (mid) isn’t associated with any program or is not
allowed in this context.

You might need to install other software to open this address."

It is for me as user to set it, and not for Org to think how user is
to customize or use other software.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* AW <alexander.willand@t-online.de> [2023-01-22 00:33]:
> Workflow: E-Mails with a question comes in, I open a TODO heading in
> an orgmode file regarding the question.
> 
> Now, I'd like to add a link to the E-Mail under this TODO heading in the 
> orgmode file. I've seen the manual page about external links, https://
> orgmode.org/manual/External-Links.html 

I am using Mutt: https://mutt.org which must be in your
distribution. 

There is way how to automatically capture Message-ID and put it
outside of the Mutt, though I did not yet implement it.

However, if I wish to open specific e-mail I point to the Maildir, or
maybe Mbox or other type,

Maildir: /home/data1/protected/Maildir/tomas@tuxteam.de
Message-ID: Y0mt4/G+DlKlURuC@tuxteam.de

Then I use this function:

(defun hyperscope-mutt-view-by-message-id (link argument)
  "Opens email by message ID by using mutt"
  (let* ((folder link)
	 (message-id (replace-regexp-in-string "=" "\\\\=" argument))
	 (push (format "push '<search>=i %s<enter><enter>'" message-id)))
    (call-process "xterm" nil nil nil "-e" "mutt" "-f" folder "-e" push)))

Where by function must receive LINK and ARGUMENT, whereby ARGUMENT
means Message-ID string.

xterm is called, mutt launched for FOLDER which is same as LINK, and
"-e" specify a command to be executed after initialization, which is
in this case "push "'<search>=i Y0mt4/G+DlKlURuC@tuxteam.de<enter><enter>'"

And I get to see that specific e-mail that was hyperlinked.

You may implement this in org by creating elisp: type of links easy. You could call this function different:

(defalias 'my-message-id 'hyperscope-mutt-view-by-message-id)

(my-message-id LINK ARGUMENT)

Opens email by message ID by using mutt

[[elisp:(my-message-id "/home/data1/protected/Maildir/tomas@tuxteam.de" "Y0mt4/G+DlKlURuC@tuxteam.de")][Link to my message]]

And after clicking on the above Org hyperlink I can see it works well. 

KMail does not work on my side, so you can see which command line
options are available to find message by Message-ID.

In Thunderbird you may use this plugin:

Copy Message ID :: Add-ons for Thunderbird:
https://addons.thunderbird.net/en-us/thunderbird/addon/copy-message-id/

as to get quickly Message-ID.

The way to open up in Thunderbird is:

./thunderbird mid:PUT-HERE-YOUR-MESSAGE-ID

Here is easier way to insert Message-ID hyperlinks:

(defun rcd-org-link-message-id-by-elisp ()
  (interactive)
  (let* ((my-selection (gui-selection-value))
	 (functions '("(my-message-id \"%s\" \"%s\")" "(message-id-by-thunderbird \"%s\")"))
	 (function (completing-read "Choose function for Message-ID: " functions nil t))
	 (name (read-string "Name of link: "))
	 (folder (read-string "Enter mail folder if any or RET for nothing: "))
	 (message-id (read-string "Enter Message-ID: " my-selection)))
    (insert "[[elisp:" (format function folder message-id) "][" name "]]")))

1. Copy Message ID in memory, but you also need to know Mail folder, depending of function

2. M-x rcd-org-link-message-id-by-elisp and answer questions

3. [[elisp:(my-message-id "my mail folder" "my message ID")][my name]]

> I'm on Linux, KDE as GUI, distro Tumbleweed by openSUSE. The E-mail
> software is kmail. Unfortunately, there is no way to get the path to
> an individual E- mail out of kmail, which I could simply use to put
> it into my orgmode file as a link.  So I installed notmuchmail and
> the emacs package notmuch.el.

It requires indexing and wastes time. If you use Mutt, it will open up
Message-ID e-mails in breeze. You may invoke external HTML viewers or
external program to see e-mails in different way. I know it is double
work.

Peculiar ways to make Evolution work are explained by Karl Voit:

Moving from Thunderbird to Evolution for Emails and Calendar:
https://karl-voit.at/2021/06/01/Thunderbird-to-Evolution/

Feature request: getting a message-id link from email + CLI option to open email via message-id (#1508) · Issues · GNOME / evolution · GitLab:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1508

> By notmuch-search I can find an individual E-mail. In the E-Mail
> buffer I type c I , which copies the message-ID of that E-Mail into
> the keyring.  Instead of a link I paste the message-ID into my
> orgmode file. If I'd like to read the E-Mail again, I can use
> notmuch-search: id: <abc123> to find the E- Mail again.  I know,
> this is not a really efficient way. Probably you are not surprised
> to read my question: How can I have a link in an orgmode file to an
> E-Mail using either a feature of kmail oder notmuch ?  Regards,

We tried to solve this problem for Mutt here, since 3 years already:

Feature proposal: provide possibility to link directly to a message (#172) · Issues · Mutt Project / mutt · GitLab:
https://gitlab.com/muttmua/mutt/-/issues/172

Of course, one can see that both in Gnome and Mutt society, people
hardly understand use cases of capturing hyperlinks to messages.

Capturing of e-mails attributes is more of a problem that creating
hyperlinks in Org.

Good that Mutt supports Muttlisp language. But I do not use it. I did
not figure out yet how to make IMAP hyperlinks, but that is definitely
possible. 

Here is how to capture Hyperlinks by using Mutt:
------------------------------------------------

.muttrc settings
----------------

##############
# Folder hooks
##############

folder-hook . 'set my_folder=$folder;set folder="XXX";set visual=^'
folder-hook . 'setenv MUTTCURRENTFOLDER $visual'
folder-hook . 'set folder=$my_folder'

macro index,pager \em ":set wait_key=no<enter><pipe-entry>grep -i -o -P '(?<=Message-Id: <).*(?=>)' | sed 's%\(.*\)%'\"$MUTTCURRENTFOLDER\"'###\1%' | capture-mutt-message-id.sh $folder<enter>"

File: capture-mutt-message-id.sh
--------------------------------

#!/usr/bin/bash
read -r message_id
folder="$@"
echo "Got folder: $folder with Message-ID: $message_id"
emacsclient -e "(rcd-mutt-capture-message-id \"$folder\" \"$message_id\")"
sleep 3


Emacs Lisp function:
--------------------

This function shall be adapted to be used in Org. There is name,
folder and message-id to be used.

(defun rcd-mutt-capture-message-id (folder message-id)
  "Create new Hyperdocument by using FOLDER and MESSAGE-ID."
  (raise-frame)
  (x-focus-frame nil)
  (let* ((name (rcd-ask-get "Name for the Message-ID Hyperdocument: "))
	 (parent (hyperscope-select-set "Parent set for Message-ID: "))
	 (id (hyperscope-add-generic name folder nil 22 nil parent message-id)))
    (rcd-message "Captured Hyperdocument ID: %s Message-ID with folder: %s, and Message-ID: %s" id folder message-id)
    (hyperscope-isolate id)))

Mutt workflow:
--------------

0. It uses Emacs in background, program `emacsclient' should be
   capable of connecting to Emacs server

1. Open up any e-mail, never mind where it is:

2. press `ESC m' to capture Message ID as hyperlink

3. Emacs will raise it's frame, describe the hyperlink to that Message-ID

4. Continue reading e-mails


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Bruno Barbier <brubar.cs@gmail.com> writes:

> Max Nikulin <manikulin@gmail.com> writes:

>> If Message-ID still can be decoded from cb_thinderlink URIs than it 
>> should be possible adapt orco to handle such links as well.

I'm using plain Message-IDs to identify my emails, and, when choosing an
email client, that's really the first feature that I'm checking.

In Thunderbird, in the cb_thunderlink config (v 1.6.0), I'm using a link format
that is compatible with the old thunderlink extension:

     [[email:$msgid$][$author_name$: $subject$ ($date_iso$)]]

     
To open a message whose "Message-ID" is 'message-id', org just
requests my operating system to open a link like:

     (concat "thunderlink://messageid=" message-id)


It looks like thunderbird allows to search for Message-ID (see
headerMessageId):

   https://webextension-api.thunderbird.net/en/stable/messages.html#messages-query
   
and there is no warning about using it. I'm guessing that cb_thunderlink
is using this.

Hope this may help,

Bruno