From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:aacc::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12 with LMTPS id oC82BGBDtmHVPgAAsNZ9tg (envelope-from ) for ; Sun, 12 Dec 2021 18:45:52 +0000 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id cMt0O19DtmGeBgAAbx9fmQ (envelope-from ) for ; Sun, 12 Dec 2021 18:45:51 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1639334750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MQC7Le4oDMhXbYbsQOBaRM4+abRDrJUAmA5BbDon9rY=; b=y9OljyEZcXjrbZ7Hbc87POOGuXwkYPu8EHROZZ5U96DZ37VJ9sezvgEVFgs+J7dt4aJuUb 0IO2KdYCJcX0SvJdM7Gex4dJC6PYZdDTFhC7kwvvZ4Vw+zHSXVscxlCfDFzTbZSR86TVt6 /AGo/dtQ+l4PVJPJXlUXyT1nDLts+qJpKGQA5hsV6OjaTiAj3J8B4qvqSy14n/RV7juDM7 0+OQxP4fYurtqMS7SWHgwXqCHLTUt3wwiOCjSVRX453x4f8y9ZQlk9fxmrH9r2tdDAoRu/ MqG3hMnA8mi3Hl/t905dbek8aw/odYwG3vgZCf4N8MDSnQVLq9eZX3/heGbZ1A== From: Kyle Meyer To: Leo Cc: piem@inbox.kyleam.com, Sean Whitton , Xinglu Chen Subject: Re: [PATCH 1/1] Use notmuch-extract-patch if available In-Reply-To: <87k0ga85yf.fsf@relevant-information.com> References: <20211209204319.168897-1-sourcehut@relevant-information.com> <20211209204319.168897-2-sourcehut@relevant-information.com> <87mtl66ckv.fsf@kyleam.com> <87k0ga85yf.fsf@relevant-information.com> Date: Sun, 12 Dec 2021 13:45:48 -0500 Message-ID: <87ilvt64rn.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: kyle@kyleam.com X-TUID: avWN+jhPbKh5 [ +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 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.