Hi Darek, On Wed, Nov 15, 2023 at 01:25:29PM -0500, Derek Martin wrote: > On Wed, Nov 15, 2023 at 07:10:52PM +0100, Alejandro Colomar wrote: > > On Wed, Nov 15, 2023 at 04:13:14PM +0100, Werner Koch wrote: > > > Hi! > > > > > > On Fri, 10 Nov 2023 01:41, Alejandro Colomar said: > > > > > > > This is breaking behavior, so it needs some more justification than just > > > > the above. > > > > > > FWIW, I am using another patch for 2 years now to send unattended but > > > signed mails. The patch requires a new option to avoid the risk of > > > regressions. See > > > > > > > > > https://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20220725/thread.html > > > > > > and Kevin's follow-up. Unfortunately I had not have the time to > > > continue working on the patch to get this or something else upstream. > > > > Hmm. Interesting. I think I prefer not adding an option. It's > > breaking behavior > > So, acknowledging that this discussion is mostly academic since > there seems not to be anyone to maintain/support new features...
Yes, it's still academic and useful, since I plan to patch neomutt(1) in the same way (and neomutt(1) is still maintained). Only problem with neomutt(1) is it doesn't seem to be compatible with mutt(1), in that `neomutt -H -` doesn't seem to work. (I reported that as a bug to neomutt(1), although it seems they removed the feature on purpose a few, years ago, which seems confusing to me.) And of course, knowing what mutt(1) users think of the feature, would be interesting. > > > but at least it keeps it simple: you enable crypto in > > the config, you get crypto. > > No it doesn't. I use both encryption and unattended mail, and I don't > use gpg-agent or equivalent, quite intentionally, as I want the choice > to use encryption to be quite deliberate, requiring me to type my > passphrase each time I do so. Your method completely breaks me. No > thanks. You could use a different config for those unattended actions. For example, you could source ~/.config/mutt/crypto.muttrc from your .muttrc, but use a different .muttrc that doesn't include crypto.muttrc in those unattended operations (you could use `mutt -F unattended.muttrc` for that). If I were writing mutt(1) from scratch, I'd say that's the sanest way to do this, instead of not enabling a feature in those cases. > > Besides which, this is Mutt's longstanding development philosophy. It > violates principle of least surprise. An option is required. [And > this, from a guy who hates adding options...] Yeah, similar conflict in my head. :) Cheers, Alex > > -- > Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 > -=-=-=-=- > This message is posted from an invalid address. Replying to it will result in > undeliverable mail due to spam prevention. Sorry for the inconvenience. > -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
