* [PATCH 0/1] Use notmuch-extract-patch if available @ 2021-12-09 20:43 sourcehut 2021-12-09 20:43 ` [PATCH 1/1] " sourcehut 0 siblings, 1 reply; 13+ messages in thread From: sourcehut @ 2021-12-09 20:43 UTC (permalink / raw) To: piem; +Cc: Leo From: Leo <sourcehut@relevant-information.com> Instead of getting all the messages in the thread like my last patch I thought using notmuch-extract-patch would be cleaner. The code is adapted from elpa-mailscripts that is linked from the piem's documentation. It might be a good alternative to b4. Leo (1): Use notmuch-extract-patch if available piem-notmuch.el | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) base-commit: b8eec6b96ed91c408f5ba3fef614c031cb5b50d7 -- 2.31.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-09 20:43 [PATCH 0/1] Use notmuch-extract-patch if available sourcehut @ 2021-12-09 20:43 ` sourcehut 2021-12-11 21:44 ` Kyle Meyer 2021-12-12 19:26 ` Sean Whitton 0 siblings, 2 replies; 13+ messages in thread From: sourcehut @ 2021-12-09 20:43 UTC (permalink / raw) To: piem; +Cc: Leo From: Leo <sourcehut@relevant-information.com> notmuch-extract-patch is a command line tool from the elpa-mailscripts package that extracts patches from a thread. It's a useful way to extract the latest patch series from an email thread and filter out the replies and reviews. --- piem-notmuch.el | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/piem-notmuch.el b/piem-notmuch.el index 8b2a353..05c03ab 100644 --- a/piem-notmuch.el +++ b/piem-notmuch.el @@ -81,7 +81,9 @@ (defun piem-notmuch-am-ready-mbox () "Return a function that inserts an am-ready mbox. If the buffer has any MIME parts that look like a patch, use those parts' contents (in order) as the mbox. Otherwise, use the -message itself if it looks like a patch." +message itself if it looks like a patch. If the executable +notmuch-extract-patch exists on the path, use that to get the +latest patch series from the notmuch thread." (when (derived-mode-p 'notmuch-show-mode) (let* ((handle (piem-notmuch--with-current-message (mm-dissect-buffer))) @@ -90,10 +92,25 @@ (defun piem-notmuch-am-ready-mbox () (if (= n-attachments 0) (when (string-match-p piem-patch-subject-re (notmuch-show-get-subject)) - (let ((id (notmuch-show-get-message-id))) + (let ((id (notmuch-show-get-message-id)) + (thread-id notmuch-show-thread-id)) (lambda () - (call-process notmuch-command nil t nil - "show" "--format=mbox" id)))) + (if-let ((cmd (executable-find "notmuch-extract-patch")) + (tid + ;; If `notmuch-show' was called with a notmuch query rather + ;; than a thread ID, as `org-notmuch-follow-link' in + ;; org-notmuch.el does, then `notmuch-show-thread-id' might + ;; be an arbitrary notmuch query instead of a thread ID. We + ;; need to wrap such a query in thread:{} before passing it + ;; to notmuch-extract-patch(1), or we might not get a whole + ;; thread extracted (e.g. if the query is just id:foo) + (if (string= (substring thread-id 0 7) "thread:") + thread-id + (concat "thread:{" thread-id "}")))) + (call-process cmd nil t nil + tid) + (call-process notmuch-command nil t nil + "show" "--format=mbox" id))))) (notmuch-foreach-mime-part (lambda (p) (when-let ((patch (piem-am-extract-attached-patch p))) -- 2.31.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-09 20:43 ` [PATCH 1/1] " sourcehut @ 2021-12-11 21:44 ` Kyle Meyer 2021-12-12 9:44 ` Leo 2021-12-14 11:36 ` Leo 2021-12-12 19:26 ` Sean Whitton 1 sibling, 2 replies; 13+ messages in thread From: Kyle Meyer @ 2021-12-11 21:44 UTC (permalink / raw) To: sourcehut; +Cc: piem sourcehut@relevant-information.com writes (in cover letter): > Instead of getting all the messages in the thread like my last patch I thought > using notmuch-extract-patch would be cleaner. The code is adapted from > elpa-mailscripts that is linked from the piem's documentation. It might be a > good alternative to b4. sourcehut@relevant-information.com writes (in commit message): > notmuch-extract-patch is a command line tool from the elpa-mailscripts > package that extracts patches from a thread. It's a useful way to > extract the latest patch series from an email thread and filter out the > replies and reviews. It's been a little while since I've looked over mailscripts, but I think it's got a lot of neat functionality (and in general am excited to see work in this space). I obviously decided to focus piem's patch extraction functionality around b4, but I'm happy to consider some support for notmuch-extract-patch if there are people that 1) want to use notmuch-extract-patch and 2) for whatever reason, prefer to use piem rather than mailscripts.el. > diff --git a/piem-notmuch.el b/piem-notmuch.el > index 8b2a353..05c03ab 100644 > --- a/piem-notmuch.el > +++ b/piem-notmuch.el > @@ -81,7 +81,9 @@ (defun piem-notmuch-am-ready-mbox () > "Return a function that inserts an am-ready mbox. > If the buffer has any MIME parts that look like a patch, use > those parts' contents (in order) as the mbox. Otherwise, use the > -message itself if it looks like a patch." > +message itself if it looks like a patch. If the executable > +notmuch-extract-patch exists on the path, use that to get the > +latest patch series from the notmuch thread." > (when (derived-mode-p 'notmuch-show-mode) > (let* ((handle (piem-notmuch--with-current-message > (mm-dissect-buffer))) > @@ -90,10 +92,25 @@ (defun piem-notmuch-am-ready-mbox () > (if (= n-attachments 0) > (when (string-match-p piem-patch-subject-re > (notmuch-show-get-subject)) > - (let ((id (notmuch-show-get-message-id))) > + (let ((id (notmuch-show-get-message-id)) > + (thread-id notmuch-show-thread-id)) > (lambda () > - (call-process notmuch-command nil t nil > - "show" "--format=mbox" id)))) > + (if-let ((cmd (executable-find "notmuch-extract-patch")) > + (tid > + ;; If `notmuch-show' was called with a notmuch query rather > + ;; than a thread ID, as `org-notmuch-follow-link' in > + ;; org-notmuch.el does, then `notmuch-show-thread-id' might > + ;; be an arbitrary notmuch query instead of a thread ID. We > + ;; need to wrap such a query in thread:{} before passing it > + ;; to notmuch-extract-patch(1), or we might not get a whole > + ;; thread extracted (e.g. if the query is just id:foo) > + (if (string= (substring thread-id 0 7) "thread:") > + thread-id > + (concat "thread:{" thread-id "}")))) I believe this comment and (if ...) is coming straight from mailscripts.el. You note in the cover letter that some of this is copied from mailscripts.el, but I think there should be a code comment as well. However, I don't really understand why the condition is necessary. Wouldn't always using thread:{notmuch-show-get-message-id return value} work? > + (call-process cmd nil t nil > + tid) > + (call-process notmuch-command nil t nil > + "show" "--format=mbox" id))))) Rather than add this functionality to piem-notmuch-am-ready-mbox, I'd prefer to add a dedicated function for notmuch-extract-patch. Then this function can be added instead of (or even just ahead of) piem-notmuch-am-ready-mbox in piem-am-ready-mbox-functions. Whether that function is added to piem-am-ready-mbox-functions could be controlled by a user option. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-11 21:44 ` Kyle Meyer @ 2021-12-12 9:44 ` Leo 2021-12-12 18:45 ` Kyle Meyer 2021-12-14 11:36 ` Leo 1 sibling, 1 reply; 13+ messages in thread From: Leo @ 2021-12-12 9:44 UTC (permalink / raw) To: Kyle Meyer; +Cc: piem Kyle Meyer <kyle@kyleam.com> writes: > > It's been a little while since I've looked over mailscripts, but I think > it's got a lot of neat functionality (and in general am excited to see > work in this space). I obviously decided to focus piem's patch > extraction functionality around b4, but I'm happy to consider some > support for notmuch-extract-patch if there are people that 1) want to > use notmuch-extract-patch and 2) for whatever reason, prefer to use piem > rather than mailscripts.el. > I've looked a bit at mailscripts.el and it serves as a thin wrapper around the perl scripts in the same repo. It has two features: 1) some light integration with debbugs and 2) apply the patch in this message/thread to a repo chosen by project.el/projectile. 2) is basically the same as piem except that it prompts the user for a project (every time). I feel like there is an opportunity here to reduce fragmentation and make piem the main interface to mailscripts. mailscripts.el is very short and just with this patch it supports half the functionality of mailscripts.el. This would of course require communication with the maintainers of mailscripts and a non-trivial amount of work. I'll get back to the comments on the patch later. -- ---Leo ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-12 9:44 ` Leo @ 2021-12-12 18:45 ` Kyle Meyer 2021-12-12 19:33 ` Sean Whitton 0 siblings, 1 reply; 13+ messages in thread From: Kyle Meyer @ 2021-12-12 18:45 UTC (permalink / raw) To: Leo; +Cc: piem, Sean Whitton, Xinglu Chen [ +cc Sean for awareness, more context at https://inbox.kyleam.com/piem/20211209204319.168897-1-sourcehut@relevant-information.com/T/#u ] Leo writes: > Kyle Meyer <kyle@kyleam.com> writes: > >> It's been a little while since I've looked over mailscripts, but I think >> it's got a lot of neat functionality (and in general am excited to see >> work in this space). I obviously decided to focus piem's patch >> extraction functionality around b4, but I'm happy to consider some >> support for notmuch-extract-patch if there are people that 1) want to >> use notmuch-extract-patch and 2) for whatever reason, prefer to use piem >> rather than mailscripts.el. > > I've looked a bit at mailscripts.el and it serves as a thin wrapper > around the perl scripts in the same repo. It has two features: 1) some > light integration with debbugs and 2) apply the patch in this > message/thread to a repo chosen by project.el/projectile. 2) is > basically the same as piem except that it prompts the user for a project > (every time). > > I feel like there is an opportunity here to reduce > fragmentation and make piem the main interface to mailscripts. > mailscripts.el is very short and just with this patch it supports half > the functionality of mailscripts.el. This would of course require > communication with the maintainers of mailscripts and a non-trivial > amount of work. Hmm. When thinking about unifying anything here, I suppose a core issue is the same thing that came up in another thread (<87y2gs374y.fsf@kyleam.com>), where I said (slightly edited): A related, larger issue here is my choice to focus piem on public-inbox even though many users may only be interested in the functionality for applying patches. Working on projects without a public-inbox archive is supported to some degree [4], and notmuch users can even process patches with b4, but that just kind of fell together rather than being a goal (even more so because mailscripts already covered this). My primary interest with piem is public-inbox, and there's some very exciting work upstream on a local client [5] that I plan to support. [...] [4] https://docs.kyleam.com/piem/Applying-patches-without-a-public_002dinbox-archive.html [5] https://public-inbox.org/meta/20201215114722.27400-1-e@80x24.org/ Given this focus, I doubt mailscripts would want to pull in piem to use its functionality for applying patches. And at the same time, there doesn't seem to be quite enough meat or complexity in the patch application code that it'd be worth having an upstream library that both piem and mailscripts could depend on. My view on it at this point is that piem and mailscripts have a different focus, and I don't think users having a few options in this area is a bad thing. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-12 18:45 ` Kyle Meyer @ 2021-12-12 19:33 ` Sean Whitton 2021-12-12 19:49 ` Kyle Meyer 2021-12-13 11:45 ` Leo 0 siblings, 2 replies; 13+ messages in thread From: Sean Whitton @ 2021-12-12 19:33 UTC (permalink / raw) To: Kyle Meyer; +Cc: Leo, piem, Xinglu Chen, sgo-software-discuss, mailscripts [-- Attachment #1: Type: text/plain, Size: 2700 bytes --] Hello Kyle, Leo, On Sun, Dec 12, 2021 at 01:45:48PM -0500, Kyle Meyer wrote: > [ +cc Sean for awareness, more context at > https://inbox.kyleam.com/piem/20211209204319.168897-1-sourcehut@relevant-information.com/T/#u ] Thank you for the CC, much appreciated. Looping in the mailing list used for mailscripts devel. > Leo writes: > > > Kyle Meyer <kyle@kyleam.com> writes: > > > >> It's been a little while since I've looked over mailscripts, but I think > >> it's got a lot of neat functionality (and in general am excited to see > >> work in this space). I obviously decided to focus piem's patch > >> extraction functionality around b4, but I'm happy to consider some > >> support for notmuch-extract-patch if there are people that 1) want to > >> use notmuch-extract-patch and 2) for whatever reason, prefer to use piem > >> rather than mailscripts.el. > > > > I've looked a bit at mailscripts.el and it serves as a thin wrapper > > around the perl scripts in the same repo. It has two features: 1) some > > light integration with debbugs and 2) apply the patch in this > > message/thread to a repo chosen by project.el/projectile. 2) is > > basically the same as piem except that it prompts the user for a project > > (every time). > > > > I feel like there is an opportunity here to reduce > > fragmentation and make piem the main interface to mailscripts. > > mailscripts.el is very short and just with this patch it supports half > > the functionality of mailscripts.el. This would of course require > > communication with the maintainers of mailscripts and a non-trivial > > amount of work. mailscripts.el is the weakest part of mailscripts -- I think the scripts are pretty solid, but the Emacs integration is immature. If what you're suggesting here is using piem as a better Emacs frontend to the scripts, somehow subsuming mailscripts.el into piem, that sounds like it could make things better. > Given this focus, I doubt mailscripts would want to pull in piem to use > its functionality for applying patches. And at the same time, there > doesn't seem to be quite enough meat or complexity in the patch > application code that it'd be worth having an upstream library that both > piem and mailscripts could depend on. I'm not sure but I *think* what Leo is suggesting is that piem be the frontend and mailscripts' functionality gets used to apply patches ..? > My view on it at this point is that piem and mailscripts have a > different focus, and I don't think users having a few options in this > area is a bad thing. We should probably go ahead and add links to each other in the READMEs? -- Sean Whitton [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-12 19:33 ` Sean Whitton @ 2021-12-12 19:49 ` Kyle Meyer 2021-12-14 19:12 ` Sean Whitton 2021-12-13 11:45 ` Leo 1 sibling, 1 reply; 13+ messages in thread From: Kyle Meyer @ 2021-12-12 19:49 UTC (permalink / raw) To: Sean Whitton; +Cc: Leo, piem, Xinglu Chen, sgo-software-discuss, mailscripts Sean Whitton writes: > On Sun, Dec 12, 2021 at 01:45:48PM -0500, Kyle Meyer wrote: [...] >> My view on it at this point is that piem and mailscripts have a >> different focus, and I don't think users having a few options in this >> area is a bad thing. > > We should probably go ahead and add links to each other in the READMEs? Sure, will do. And piem's documentation already points to mailscripts in a couple of spots: $ git grep mailscripts Documentation/piem.texi:@cindex mailscripts Documentation/piem.texi:checking out @url{https://git.spwhitton.name/mailscripts/,mailscripts}, Documentation/piem.texi:@cindex mailscripts Documentation/piem.texi:mailscripts, mentioned earlier in the manual (@pxref{Applying patches Documentation/piem.texi:@url{https://git.spwhitton.name/mailscripts/} ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-12 19:49 ` Kyle Meyer @ 2021-12-14 19:12 ` Sean Whitton 0 siblings, 0 replies; 13+ messages in thread From: Sean Whitton @ 2021-12-14 19:12 UTC (permalink / raw) To: Kyle Meyer; +Cc: Leo, piem, Xinglu Chen, sgo-software-discuss, mailscripts Hello, On Sun 12 Dec 2021 at 02:49PM -05, Kyle Meyer wrote: > Sean Whitton writes: > >> On Sun, Dec 12, 2021 at 01:45:48PM -0500, Kyle Meyer wrote: > [...] >>> My view on it at this point is that piem and mailscripts have a >>> different focus, and I don't think users having a few options in this >>> area is a bad thing. >> >> We should probably go ahead and add links to each other in the READMEs? > > Sure, will do. Added to notmuch-extract-patch(1) too. -- Sean Whitton ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-12 19:33 ` Sean Whitton 2021-12-12 19:49 ` Kyle Meyer @ 2021-12-13 11:45 ` Leo 1 sibling, 0 replies; 13+ messages in thread From: Leo @ 2021-12-13 11:45 UTC (permalink / raw) To: Sean Whitton, Kyle Meyer Cc: piem, Xinglu Chen, sgo-software-discuss, mailscripts Sean Whitton <spwhitton@spwhitton.name> writes: > On Sun, Dec 12, 2021 at 01:45:48PM -0500, Kyle Meyer wrote: > >> Given this focus, I doubt mailscripts would want to pull in piem to use >> its functionality for applying patches. And at the same time, there >> doesn't seem to be quite enough meat or complexity in the patch >> application code that it'd be worth having an upstream library that both >> piem and mailscripts could depend on. > > I'm not sure but I *think* what Leo is suggesting is that piem be the > frontend and mailscripts' functionality gets used to apply patches ..? > Yeah, pretty much. Piem already feels pretty general with support for gnus, notmuch, b4, eww and elfeed so adding mailscripts doesn't feel like a big leap. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-11 21:44 ` Kyle Meyer 2021-12-12 9:44 ` Leo @ 2021-12-14 11:36 ` Leo 2021-12-20 6:45 ` Sean Whitton 1 sibling, 1 reply; 13+ messages in thread From: Leo @ 2021-12-14 11:36 UTC (permalink / raw) To: Kyle Meyer; +Cc: piem, Sean Whitton Kyle Meyer <kyle@kyleam.com> writes: > sourcehut@relevant-information.com writes: >> + (if-let ((cmd (executable-find "notmuch-extract-patch")) >> + (tid >> + ;; If `notmuch-show' was called with a notmuch query rather >> + ;; than a thread ID, as `org-notmuch-follow-link' in >> + ;; org-notmuch.el does, then `notmuch-show-thread-id' might >> + ;; be an arbitrary notmuch query instead of a thread ID. We >> + ;; need to wrap such a query in thread:{} before passing it >> + ;; to notmuch-extract-patch(1), or we might not get a whole >> + ;; thread extracted (e.g. if the query is just id:foo) >> + (if (string= (substring thread-id 0 7) "thread:") >> + thread-id >> + (concat "thread:{" thread-id "}")))) > > I believe this comment and (if ...) is coming straight from > mailscripts.el. You note in the cover letter that some of this is > copied from mailscripts.el, but I think there should be a code comment > as well. > > However, I don't really understand why the condition is necessary. > Wouldn't always using > > thread:{notmuch-show-get-message-id return value} > > work? I don't actually know, maybe Sean Whitton knows? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-14 11:36 ` Leo @ 2021-12-20 6:45 ` Sean Whitton 0 siblings, 0 replies; 13+ messages in thread From: Sean Whitton @ 2021-12-20 6:45 UTC (permalink / raw) To: Leo, Kyle Meyer; +Cc: piem Hello, On Tue 14 Dec 2021 at 12:36PM +01, Leo wrote: > Kyle Meyer <kyle@kyleam.com> writes: > >> sourcehut@relevant-information.com writes: >>> + (if-let ((cmd (executable-find "notmuch-extract-patch")) >>> + (tid >>> + ;; If `notmuch-show' was called with a notmuch query rather >>> + ;; than a thread ID, as `org-notmuch-follow-link' in >>> + ;; org-notmuch.el does, then `notmuch-show-thread-id' might >>> + ;; be an arbitrary notmuch query instead of a thread ID. We >>> + ;; need to wrap such a query in thread:{} before passing it >>> + ;; to notmuch-extract-patch(1), or we might not get a whole >>> + ;; thread extracted (e.g. if the query is just id:foo) >>> + (if (string= (substring thread-id 0 7) "thread:") >>> + thread-id >>> + (concat "thread:{" thread-id "}")))) >> >> I believe this comment and (if ...) is coming straight from >> mailscripts.el. You note in the cover letter that some of this is >> copied from mailscripts.el, but I think there should be a code comment >> as well. >> >> However, I don't really understand why the condition is necessary. >> Wouldn't always using >> >> thread:{notmuch-show-get-message-id return value} >> >> work? > > I don't actually know, maybe Sean Whitton knows? I guess if you are using the function notmuch-show-get-message-id rather than the variable notmuch-show-thread-id, then it sounds like just wrapping that in thread:{} would work. But it has been some years since I figured out that code, I'm afraid. -- Sean Whitton ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-09 20:43 ` [PATCH 1/1] " sourcehut 2021-12-11 21:44 ` Kyle Meyer @ 2021-12-12 19:26 ` Sean Whitton 2021-12-13 11:53 ` Leo 1 sibling, 1 reply; 13+ messages in thread From: Sean Whitton @ 2021-12-12 19:26 UTC (permalink / raw) To: sourcehut, piem [-- Attachment #1: Type: text/plain, Size: 1476 bytes --] Hello, On Thu, Dec 09, 2021 at 09:43:19PM +0100, Leo <sourcehut@relevant-information.com> wrote: > From: Leo <sourcehut@relevant-information.com> > > notmuch-extract-patch is a command line tool from the elpa-mailscripts > package that extracts patches from a thread. It's a useful way to > extract the latest patch series from an email thread and filter out the > replies and reviews. > --- > piem-notmuch.el | 25 +++++++++++++++++++++---- > 1 file changed, 21 insertions(+), 4 deletions(-) > > diff --git a/piem-notmuch.el b/piem-notmuch.el > index 8b2a353..05c03ab 100644 > --- a/piem-notmuch.el > +++ b/piem-notmuch.el > + (tid > + ;; If `notmuch-show' was called with a notmuch query rather > + ;; than a thread ID, as `org-notmuch-follow-link' in > + ;; org-notmuch.el does, then `notmuch-show-thread-id' might > + ;; be an arbitrary notmuch query instead of a thread ID. We > + ;; need to wrap such a query in thread:{} before passing it > + ;; to notmuch-extract-patch(1), or we might not get a whole > + ;; thread extracted (e.g. if the query is just id:foo) This text comment is lifted straight from mailscripts.el, so please be sure to add "(C) 2019 Sean Whitton <spwhitton@spwhitton.name" to the copyright notices for this file. It's GPL-3+ so nothing else needed. Glad that mailscripts.el proved useful in the development of this patch :) -- Sean Whitton [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] Use notmuch-extract-patch if available 2021-12-12 19:26 ` Sean Whitton @ 2021-12-13 11:53 ` Leo 0 siblings, 0 replies; 13+ messages in thread From: Leo @ 2021-12-13 11:53 UTC (permalink / raw) To: Sean Whitton, piem Sean Whitton <spwhitton@spwhitton.name> writes: > This text comment is lifted straight from mailscripts.el, so please be > sure to add "(C) 2019 Sean Whitton <spwhitton@spwhitton.name" to the > copyright notices for this file. It's GPL-3+ so nothing else needed. > Sure thing! ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-12-20 6:45 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-09 20:43 [PATCH 0/1] Use notmuch-extract-patch if available sourcehut 2021-12-09 20:43 ` [PATCH 1/1] " sourcehut 2021-12-11 21:44 ` Kyle Meyer 2021-12-12 9:44 ` Leo 2021-12-12 18:45 ` Kyle Meyer 2021-12-12 19:33 ` Sean Whitton 2021-12-12 19:49 ` Kyle Meyer 2021-12-14 19:12 ` Sean Whitton 2021-12-13 11:45 ` Leo 2021-12-14 11:36 ` Leo 2021-12-20 6:45 ` Sean Whitton 2021-12-12 19:26 ` Sean Whitton 2021-12-13 11:53 ` Leo
Code repositories for project(s) associated with this public inbox https://git.kyleam.com/piem/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).