Re: [PATCH 1/1] Use notmuch-extract-patch if available

[Kyle Meyer <kyle@kyleam.com>]

[ +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.