discussion and development of piem
 help / color / mirror / code / Atom feed
From: Sean Whitton <spwhitton@spwhitton.name>
To: Kyle Meyer <kyle@kyleam.com>
Cc: Leo <sourcehut@relevant-information.com>,
	piem@inbox.kyleam.com, Xinglu Chen <public@yoctocell.xyz>,
Subject: Re: [PATCH 1/1] Use notmuch-extract-patch if available
Date: Sun, 12 Dec 2021 12:33:27 -0700	[thread overview]
Message-ID: <YbZOh0yEFLBwVUMp@melete.silentflame.com> (raw)
In-Reply-To: <87ilvt64rn.fsf@kyleam.com>

[-- 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 --]

  reply	other threads:[~2021-12-12 19:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://git.kyleam.com/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbZOh0yEFLBwVUMp@melete.silentflame.com \
    --to=spwhitton@spwhitton.name \
    --cc=kyle@kyleam.com \
    --cc=mailscripts@packages.debian.org \
    --cc=piem@inbox.kyleam.com \
    --cc=public@yoctocell.xyz \
    --cc=sgo-software-discuss@chiark.greenend.org.uk \
    --cc=sourcehut@relevant-information.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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