discussion and development of piem
 help / color / mirror / code / Atom feed
* [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-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 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: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-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

* 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-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-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

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).