Re: Is there an hyperlink type for Mutt's e-mails?

--=_e4daa1fceed28fb094d6823a80540a1a
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 2026-04-06 11:26, Sébastien Hinderer wrote:
> Many thanks for your response!
> 
> Actually, after I wrote the quesiton i managed to convince myself that
> it was meaningless because the question coudl actually make sens only
> for clients that were running inside of Emacs.

I find it so useful to capture links to messages.

> 1. With your solution the links contain the name of the folder where 
> the
> message is stored. It's not that bad but I am still wondering whether
> one couldn't use only the message id, which wold mean that the solution
> would work even if the message is moved to a different folder. Of 
> course
> that would require a kind of indexing to go frommessage ids to folders
> but does that look completely undoable?

There are various solutions. I can suggest indexing:

$ dpkg -S /usr/bin/mu
maildir-utils: /usr/bin/mu

so you could install that one from https://www.djcbsoftware.nl/code/mu/ 
and it is normally a system package.

You would index your emails.

Another more fundamental issue is that it is best indexing e-mails in 
Maildir format.

Also very fundamental, saving any incoming/outgoing e-mails for 
[email protected] in ~/Maildir/[email protected]

That alone gives you possibility to make links straight to user's bunch 
of e-mails to see any previous conversations.

Then it becomes also trivial to save/update message IDs by regular cron 
job, so that all links to message ID work.

mutt-by-message-id.sh 
"CA+OMD9h_viu0k4M+k6MJZS2GcZhUOPCNQKF5kX-rtyMpiwX-JQ@mail.gmail.com"
File path: 
/home/data1/protected/Maildir/[email protected]/cur/1620819775.32017_9.protected:2,S
Folder: /home/data1/protected/Maildir/[email protected]
Message-ID: 
CA+OMD9h_viu0k4M+k6MJZS2GcZhUOPCNQKF5kX-rtyMpiwX-JQ@mail.gmail.com

It works on my side.

So now you make Org link, something like mu:MESSAGE-ID and you will have 
xterm opening with that message.

> 2. If I understand you correctly, the part that has to be different 
> when
> done fromMutt as compared to when done from Emacs is the store link
> stage, which is, if I understand you correctly, where your macro comes
> in. But I think if oneis using Emacs in server mode then it should be
> possible to call Org's store-link feature by running emacsclient, which
> would make the link available to all the other running instances of
> emacsclient.

Yes, is possible. Though this is discussion. Maybe you could define the 
need and I can look into it.

> 3. A sllightly different topic is if one uses Org as a bookmark manager
> and wnat to store into in links that are in message bodies, rather than
> links tomessages themselves. But I assume the smae trick of invoking
> org-store-link through emacsclient could work. HAs somebody already set
> this up?

Official Message ID pattern for URLs is: mid

like 
mid:CAMNq+4YWP3xSwZHunE2vgzaiupTrMgVbKBkd3NiGFsW=DYRtPQ@mail.gmail.com

It means something like that should become link in any Emacs buffer when 
goto-address-mode is enabled. It is thus better following that pattern 
in org as well:

[[mid:CAMNq+4YWP3xSwZHunE2vgzaiupTrMgVbKBkd3NiGFsW=DYRtPQ@mail.gmail.com][Email 
about Boll Mills]]

and then it is better to use Org to open registered URI handlers for it:

goto-address-uri-schemes is a variable defined in ‘goto-addr.el’.

Its value is shown below.

List of URI schemes matched by ‘goto-address-url-regexp’.

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

Value:
("hyperscope:" "aaa://" "about:" "acap://" "apt:" "bzr://"
  "bzr+ssh://" "attachment:/" "chrome://" "cid:" "content://" "crid://"
  "cvs://" "dav:" "dict://" "doi:" "dns:" "dtn:" "feed:" "file:/"
  "finger://" "fish://" "ftp://" "geo:" "git://" "go:" "gopher://"
  "h323:" "http://" "https://" "im:" "imap://" "info:" "ipp:" "irc://"
  "irc6://" "ircs://" "iris.beep:" "jar:" "ldap://" "ldaps://"
  "magnet:" "mid:" "mtqp://" "mupdate://" "news:" "nfs://" "nntp://"
  "opaquelocktoken:" "pop://" "pres:" "resource://" "rmi://" "rsync://"
  "rtsp://" "rtspu://" "service:" "sftp://" "sip:" "sips:" "smb://"
  "sms:" "snmp://" "soap.beep://" "soap.beeps://" "ssh://" "svn://"
  "svn+ssh://" "tag:" "tel:" "telnet://" "tftp://" "tip://" "tn3270://"
  "udp://" "urn:" "uuid:" "vemmi://" "webcal://" "xri://"
  "xmlrpc.beep://" "xmlrpc.beeps://" "z39.50r://" "z39.50s://" "xmpp:"
  "gemini://" "fax:" "man:" "mms://" "mmsh://" "modem:" "prospero:"
  "snews:" "wais://")

Above is my thinking -- as the functionality should be aligned. Links 
for xmpp: defined in goto-address-uri-schemes should be automatically be 
opened in Org by whatever Emacs user has defined. Not that users have 
double definitions for standard URIs.

Here is something that works in Org:

Link:

[[mid:CAMNq+4YWP3xSwZHunE2vgzaiupTrMgVbKBkd3NiGFsW=DYRtPQ@mail.gmail.com][Email 
about Boll Mills]]

Function:

(org-link-set-parameters "mid" :follow #'goto-address-open-mid)
(defun goto-address-open-mid (msgid)
   "Open email with MSGID using mutt-by-message-id.sh.
MSGID can be passed with or without 'mid:' prefix."
   (let* ((clean-msgid (string-trim msgid "mid:" ""))
          (script (expand-file-name "~/bin/rcd/mutt-by-message-id.sh"))
          (escaped-msgid (shell-quote-argument clean-msgid)))
     (if (file-exists-p script)
         (start-process "mutt-open" nil "bash" "-c"
                        (format "%s %s" script escaped-msgid))
       (message "Script not found: %s" script))))

Org settings:

(org-link-set-parameters "mid" :follow #'goto-address-open-mid)

Script is attached.

Path must be adjusted.

It works on my side. I click the link and mutt opens on that message ID.

-- 
Jean Louis
--=_e4daa1fceed28fb094d6823a80540a1a
Content-Transfer-Encoding: base64
Content-Type: text/x-shellscript;
 name=mutt-by-message-id.sh
Content-Disposition: attachment;
 filename=mutt-by-message-id.sh;
 size=909

IyEvYmluL2Jhc2gKCk1FU1NBR0VfSUQ9IiQxIgoKaWYgWyAteiAiJE1FU1NBR0VfSUQiIF07IHRo
ZW4KICAgIGVjaG8gIkVycm9yOiBObyBNZXNzYWdlLUlEIHByb3ZpZGVkIgogICAgZXhpdCAxCmZp
CgojIEdldCB0aGUgRlVMTCBmaWxlIHBhdGgKRklMRV9QQVRIPSQobXUgZmluZCBtc2dpZDoiJE1F
U1NBR0VfSUQiIC0tZmllbGRzPSJsIiAyPi9kZXYvbnVsbCB8IGhlYWQgLTEpCgppZiBbIC16ICIk
RklMRV9QQVRIIiBdOyB0aGVuCiAgICBlY2hvICJNZXNzYWdlLUlEIG5vdCBmb3VuZDogJE1FU1NB
R0VfSUQiCiAgICBleGl0IDAKZmkKCiMgRXh0cmFjdCB0aGUgbWFpbGRpciByb290IChyZW1vdmUg
L2N1ci9maWxlbmFtZSkKIyBGcm9tOiAvaG9tZS9kYXRhMS9wcm90ZWN0ZWQvTWFpbGRpci9yc3dn
bnVAZ21haWwuY29tL2N1ci8xNjIwODE5Nzc1LjMyMDE3XzkucHJvdGVjdGVkOjIsUwojIFRvOiAg
IC9ob21lL2RhdGExL3Byb3RlY3RlZC9NYWlsZGlyL3Jzd2dudUBnbWFpbC5jb20KRk9MREVSPSQo
ZWNobyAiJEZJTEVfUEFUSCIgfCBzZWQgJ3N8L2N1ci9bXi9dKiR8fCcpCgpFU0NBUEVEX01TR0lE
PSQoZWNobyAiJE1FU1NBR0VfSUQiIHwgc2VkICdzLz0vXFw9L2cnKQoKIyBEZWJ1ZyBvdXRwdXQg
dG8gc2VlIHdoYXQncyBoYXBwZW5pbmcKZWNobyAiRmlsZSBwYXRoOiAkRklMRV9QQVRIIgplY2hv
ICJGb2xkZXI6ICRGT0xERVIiCmVjaG8gIk1lc3NhZ2UtSUQ6ICRNRVNTQUdFX0lEIgplY2hvICIi
CgojIE9wZW4gbXV0dAp4dGVybSAtZSBiYXNoIC1jICIKICAgIG11dHQgLWYgJyRGT0xERVInIC1l
ICdwdXNoIFwiPHNlYXJjaD49aSAkRVNDQVBFRF9NU0dJRDxlbnRlcj48ZW50ZXI+XCInCiAgICBl
Y2hvICdNdXR0IGV4aXRlZC4gUHJlc3MgRW50ZXIgdG8gY2xvc2UuLi4nCiAgICByZWFkCiIK
--=_e4daa1fceed28fb094d6823a80540a1a--