On Wed, Nov 15, 2023 at 09:05:15PM +0100, Alejandro Colomar wrote: > Hi Darek,
Derek.
> > 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.)
Neomutt and Mutt have different development philosophies (demonstrated
merely by the existence of both, in fact). So what's right for one
isn't necessarily what's right for the other.
> > > 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.
I'm well aware that I could, but why would I want to do that? Let's
compare and contrast the two solutions.
Werner's solution:
- Does not EVER affect anyone who does not want the new behavior
- If you do want it, requires only setting one variable, once
- The software can automatically avoid using the new behavior when
using it would be impossible.
Your solution:
- Affects every user who does not want the new behavior, every time
- Forces every affected user, individually, to think about how best
to avoid the new behavior, for their workflow and usage patterns
- Forces negatively impacted users into one or more modes they didn't
want:
• Starting an agent they may not have wanted to use to circumvent
the new behavior
• Maintaining multiple config files, for different purposes
• Having to choose between multiple config files, each and every
time the user starts Mutt, whether interactively or via script,
• etc.
Which option provides a better user experience to users, both affected
and unaffected, as a whole? If you don't think it's VERY CLEARLY the
first one, I might think maybe you should not be designing software
features...
Werner's solution is absolutely simple, and affects people the least
who care about the feature the least, and affects users the most who
have incentive to care the most, but even then requires only a very
minimal one-time effort. When you're adding a feature to software,
that's probably what you want, in most cases.
Your solution impacts most those who care the least about the new
feature, introducing numerous places where, in order to avoid the new
behavior, the user must do more work and may make a mistake on an
ongoing basis, when they have to maintain their config files, and when
they start Mutt, each and every time. It's a tedious waste of time.
Worst of all, if the user ever fails to do the thing that turns on
encryption when it was needed, your solution potentially exposes them
or their data, in a way that Werner's would not. Or rather, due to
the fallibility of humans, your solution actively makes that more
likely. I think it's fair to say it is objectively bad, for all of the
above reasons.
Now, it could be a different matter, if the feature were one that is
generally useful to most e-mail users (e.g. updating some aspect of
message generation to a new standard), and it was just a small group
of stubborn, curmudgeonly users that were affected. That's not the
case here (even if the second part might be)--this feature is only
useful to a subset of a subset of an already small community of e-mail
users.
--
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.
signature.asc
Description: PGP signature
