(Sorry for the misspelling of Mumi in the Subject thread.) (For the record, reading [1], I discovered [2,3] with similar goals than Mumi and that the Org-mode community uses public-inbox [4].)
[1] https://bzg.fr/en/org-mode-9.4-is-out-can-you-help.html/ [2] https://updates.orgmode.org/ [3] https://github.com/bzg/woof [4] https://orgmode.org/list/87r1vd92eg....@bzg.fr/ On Thu, 17 Sep 2020 at 12:00, Ricardo Wurmus <rek...@elephly.net> wrote: > zimoun <zimon.touto...@gmail.com> writes: > > 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: > > > > <issues.guix.gnu.org/HAv_FWZRa_dCADY6U07oX-E2vTrtcxk8ltkpfvTpYCsIh4O5PuItHGIh6w-g5GGmoqVEfkjDUOplpUErdGEPAiFYdrjjDhwd9RJ4OyjjGgY=@hector.link> > > > > redirecting to <http://issues.guix.gnu.org/33899#16>. > > 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. I do not know but public-inbox is doing such thing, isn't it? I mean, the example with emacs-debbugs, my "custom" function and the service <yhetil.org>: > > 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: > > > > <https://yhetil.org/guix-bugs/HAv_FWZRa_dCADY6U07oX-E2vTrtcxk8ltkpfvTpYCsIh4O5PuItHGIh6w-g5GGmoqVEfkjDUOplpUErdGEPAiFYdrjjDhwd9RJ4OyjjGgY=@hector.link> > > > > with the naive Emacs function: > > > > --8<---------------cut here---------------start------------->8--- > > (defun debbugs->url () > > (interactive) > > (let ((url "https://yhetil.org/guix-bugs/") > > 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--- Is it not enough? The URL, is it not always ready-to-be-pasted? The link contains '@' but it works (on my webbrowser at least :-)). > 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”. Thank you for explaining. > 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. Yes. If the Message-ID is also indexed, the map is almost there. > > 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 > want. Okish... CSS/JS is not really my cup of tea. I will try to rehash your words when giving a look at Mumi source. > > 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. <https://lists.gnu.org/archive/html/guix-devel/> > > to find it. > > I don’t quite understand how this differs from this: > > https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%3C86sgbhz3fe.fsf%40gmail.com%3E&submit=Search%21&idxname=guix-devel Because I did not know. :-) All the best, simon