Hi Robin, On Fri, Dec 12, 2025 at 07:12:50PM +0100, Robin Jarry wrote: > > Would you be interested in having an "aerc-muttwrapper" script be part of > > your aerc package? I can try to develop one. > > I don't think a wrapper would be a good idea. aerc isn't meant to be > a 1:1 replacement for mutt.
It doesn't have to be TBH. The context I'm using this in (our 'bts' workflow cli tool) just needs away to open MBOXes and compose replies. I've actually decided to move this idea to Debian sensible-utils as "sensible-mua"[1] so this part of the request is moot. [1]: Which was already requested all the way back in 2006 :D https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353587 > I would prefer extra work for :compose in order for it to support an > extra argument that does what you ask. Basically, it would be an > extension of the -T <template> flag but allowing to pass an arbitrary > filepath instead of just a template name. Sounds good! > We could also extend `aerc mailto:...` to accept extra arguments. That would also be nice (neo)mutt already supports this per RFC2368 "body" hname. BTW: In Debian we have at least one webservice that makes use of this to provide a pre-filled template but I can't find it now. > It depends on what you expect from aerc exactly. Do you want to start it > as part of a script so that it pops an editor open and then allows you > to send the message? Yup. That's how (neo)mutt behaves. A script starts $mutt -H /tmp/whatever. That opens a composer/editor and allows sending the message. Importantly $mutt blocks until the message is sent. > You can also use the IPC socket to control aerc from another terminal. > But you will loose the interactive part. If I get to ask for bells and wissles I would actually like to use the IPC support from within aerc, not another terminal. Both for (templated) message composition and opening MBOXes. The workflow I'm working on goes like this: I run my $MUA to browse Debian Bug emails, then - Inside $MUA I select a $message and :pipe it to our bts(1) program. - bts(1) detects it's running inside $MUA (via arcane unix magic aka. $_) and reads the message from stdin. This tells it which bug I want to work on. - If $MUA = mutt: bts(1) will spawn a nested mutt to (finish) composing the reply template bts(1) generated. (downside of nesting: eg. 'replied' flag doesn't get set) - If $MUA = aerc: we could do better here by asking the enclosing aerc (via IPC) to do the message composition after :pipe returns I would imagine the aerc IPC command would simply create a new message composition tab, but I haven't spend enough time with aerc to know what might be reasonable or expected here. For opening MBOXes at least this already seems to work how I'd expect (though I haven't spent much time exhaustively testing it yet). The relevant code is at https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/bts.pl#L1101 Notice the $aerc_I logic. > If you describe precisely what is the need, I can implement it. > I shouldn't be complicated. That would be awesome. I would love to be able to teach new people a less old and cranky MUA :-). On Sat, Dec 13, 2025 at 02:21:50PM +0000, Martin Dosch wrote: > there is a possible workaround described in that thread: > https://lists.sr.ht/~rjarry/aerc-discuss/%[email protected]%3E?__goaway_challenge=meta-refresh&__goaway_id=1d341e783e87eb7caa158658f5a83522&__goaway_referer=https%3A%2F%2Flists.sr.ht%2F~rjarry%2Faerc-discuss%3Fpage%3D4 > > For the time being I just continue to use neomutt for such tasks (and for > forwarding emails). The :import-mbox :recall hack looks plausible, I'm not sure it can be made smooth enough for the UX I have in mind tho :-). Would need to experiment more. Thanks for pointing that out Martin! --Daniel
signature.asc
Description: PGP signature
