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