From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:203:375::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12.migadu.com with LMTPS id tHQ3L7mmemS/JQEATFOONw (envelope-from ) for ; Sat, 03 Jun 2023 04:34:33 +0200 Received: from mta1.migadu.com ([2001:41d0:203:375::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id mLdjLrmmemT+AwEAauVa8A (envelope-from ) for ; Sat, 03 Jun 2023 04:34:33 +0200 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1685759673; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zG+PeRKllNktL2wL0nwoH6rUkUqO569wC6q22HgqCvQ=; b=biiKg4CFeM2Ikf2SEsRuENulRzh6PpVbwUI1F8SYtNiKpP0URP+KbG1zuMvYp8ftnjnYrT wdUHR6TU5HPsCdKxLVT8BaRYJLOujTkNBpV2g9n5A8ayH7eWEM4rb4O3/gB3ZGerkaODov 3s5UClz2RIohCfa9QLzex1QSnipvwZ41PAvaklrW1qbI98MJMcgucxRch0rxJD5EzbgACP 13YFGzpsgdBLjacTZbO5UW7WDh8k1xJKX09QawVeWIdp5w+z/UzeymTMDSO72WwHGrGZmz OHvTKUC1X28NADMyE/Cufghqury1PVeWvBkH9vOx4AYFEj1yvIFJeyjwydTqDw== From: Kyle Meyer To: Jelle Licht Cc: piem@inbox.kyleam.com Subject: Re: On the road to (GNU) debbugs support, some blockers In-Reply-To: <87o7lyi1gc.fsf@fsfe.org> References: <87y1l9ualg.fsf@fsfe.org> <87zg5l16yq.fsf@kyleam.com> <87o7lyi1gc.fsf@fsfe.org> Date: Fri, 02 Jun 2023 22:34:29 -0400 Message-ID: <87y1l1e0ju.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-TUID: rqRWZUqLx5lZ Jelle Licht writes: >> Have you tried using :listid? For example, for guix-patches, I use >> "guix-patches.gnu.org". > > I'm using the debbugs.el interface to read the messages, which > may-or-may-not present a very idiosyncratic version of the messages: > > --8<---------------cut here---------------start------------->8--- > ... > List-Id: > List-Archive: > List-Post: > List-Help: > X-GNU-PR-Package: guix-patches > ... > --8<---------------cut here---------------end--------------->8--- Ah, debbugs.el was the piece I was missing. I've played around with debbugs.el a bit in the past, but never used it for real and haven't considered it in the context of piem. >> If X-GNU-PR-Package is better than List-Id for some users/cases, I'm >> open to adding support for it. It should be sufficient to teach >> piem-inbox-by-header-match to consider that header (along with an >> associated piem-inboxes key). > > 'Better' is a big word, but the X-GNU-PR-Package header is the only one > that is really exposed via the debbugs interface afaics. I'll look into debbugs.el a bit more because I don't have a good understanding of where it's getting the messages from and how it's interacting with Gnus, but it sounds like the X-GNU-PR-Package header is the way to go for debbugs.el support. I'm curious whether it will make sense to have a custom integration library, perhaps one that builds on top of piem-gnus, but perhaps that will be clearer once I take a closer look. > As mentioned, I use debbugs.el to interact with the issue tracker. [1] > Using guix: > `guix shell emacs emacs-debbugs -- emacs': > > Evaluate: > `(debbugs-gnu '("serious" "important" "normal") '("guix-patches") nil t)' > > Go to any issue, and open a message. [...] Thanks, those concrete steps are helpful. > [1]: Not entirely relevant to the issue at hand, but I also have all > guix-patches messages available and indexed in my local notmuch > setup. When I use piem-gnus /w my modifcations, in combination with > piem-notmuch to apply patches using `piem-b4-am', the relevant messages > are actually not even downloaded from the yhetil public inbox, since the > messages with the message-ids are already found locally! Really > wonderful design and/or some convenient emergent properties of how piem > does things. I'll claim it's design, unless someone's complaining, then it's just an unfortunate emergent property :) But, yeah, the idea is that users can put local retrieval methods in piem-mid-to-thread-functions, ordered by their preferred sources, and then those sources are given priority regardless of where piem-mid is extracting the message ID from. The main downside is that a given local source that has the specified message ID doesn't necessarily have all the thread's messages. This approach has worked nicely for me because I have all of yhetil inboxes mirrored locally and indexed with lei but have yet to flesh out piem-lei enough to move away following lists via NNTP with Gnus [*]. [*] Aside from dev testing, I haven't used or relied on piem-gnus-mid-to-thread myself. My testing prompted by your message hit into some encoding issues, so it looks like it needs some work beyond the debbugs.el case you raised.