[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mummi wishlist: API using Message-ID

From: Ricardo Wurmus
Subject: Re: Mummi wishlist: API using Message-ID
Date: Thu, 17 Sep 2020 12:01:14 +0200
User-agent: mu4e 1.4.13; emacs 27.1

zimoun <> writes:

> For example <>.  The number #16 is
> really difficult to guess. :-)

Yes, it comes from the number of messages we got from Debbugs.

> Instead, it is easy to get the Message-ID.  (Using emacs-notmuch, only
> hit the key ’ci’) Therefore, it could be nice to be able to provide
> e.g., the URL:
> <>
> redirecting to <>.

This is an interesting idea!  I don’t know if it’ll work as a plain URL,
because not all characters of a message id might be usable in a URL (you
may need to URL-encode it and can’t just paste it in the URL bar of your
browser), but it would certainly work as a search query.  The only
problem is that we’re not currently indexing the message ids.

Per bug we index the bug id, the submitter, the authors, the subject(s),
the owner, the severity, the tags, the status, the file name of the
original Debbugs “.log” file (I forgot why!), and all the message
bodies.  All of these map to the very same “document” (in Xapian
parlance), which is a particular “issue”.

I think we could also index the message id (and expose it to the
search), map that to the “issue”, and then find the corresponding anchor
in the HTML later.  We wouldn’t be able to *directly* map the message id
to the actual message in the thread, because the search does not operate
on the concept of messages but only whole bug discussions.  But I think
this would get us very close to what you propose.

> And maybe the
> current webpage could provide the Message-ID, easy to copy and then
> paste in my email reader.

It’s already there but hidden!  Every message is rendered in a
div.message.  Inside of that is div.card > div.card-header > div.details
(hidden) > div.message-id.

With custom CSS you could unhide div.details, and with a custom JS you
could grab the contents of div.message-id on the click of a button.
Most browsers make it a little hard to augment the CSS and/or JS of a
served page, but with a little hacking I’m sure you can extract what you

> Another (Emacs related) example is emacs-debbugs.
>   C-u M-x debbugs-gnu RET guix RET n y
>   M-x debbugs-gnu-bugs RET 33899 RET RET
>   Read messages
> Well, in the relevant message, I run “M-x debbugs->url” and get the
> ready-to-be-pasted URL:
> <>
> with the naive Emacs function:
> --8<---------------cut here---------------start------------->8---
> (defun debbugs->url ()
>   (interactive)
>   (let ((url "";)
>         mid)
>     (with-current-buffer gnus-article-buffer
>       (gnus-summary-toggle-header 1)
>       (setq mid (message-fetch-field "Message-ID"))
>       (gnus-summary-toggle-header -1))
>     (while (string-match "[<>]" mid)
>       (setq mid (replace-match "" t t mid)))
>     (kill-new (concat url mid))
>     (message mid)))
> --8<---------------cut here---------------end--------------->8---
> Last and off-topic to the Subject :-), the tool ’public-inbox’ exposes
> such API and then it seems easier to refer to relevant message than
> going by hand on e.g. <>
> to find it.

I don’t quite understand how this differs from this:

Here I search for the id of your message (the one I’m responding to);
that’s the (URL-encoded) value of “query”, “idxname” is for the mailing
list to be searched.

It gives you a list of results, not one message directly, but I think
it’s pretty close. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]