order of sending mail and saving to fcc

[Derek Martin]

On Wed, Jun 12, 2019 at 05:20:02PM +1000, Erik Christiansen wrote:
> On 11.06.19 12:36, Derek Martin wrote:
> > I hesitate to go far as to say that if you think saving the message
> > first is the right behavior, you are simply wrong... but I'm
> > definitely thinking it. =8^)
> 
> I like your style, Derek. And respect that your use case works for you.
> What surprises me is the surplus of certitude which refuses to countenance
> a legitimate use case at variance with yours.

It's because it isn't, as I believe I've satisfactorily demonstrated.
The current behavior actually gets you literally everything you want.
It just does it differently than you expected... but it still does it.
There's no need for the Fcc first-behavior, and it is demonstrably
worse for more than one reason.  As such it should be excluded.  I can
not see how you could make any good argument to the contrary.

This is why mutt-dev rather quickly (by our standards regarding
contentious changes) agreed that the current behavior is the right
one.  We discussed it, came to a good conclusion about the solution,
it got implemented, and I think we should stick to that.  I am certain
that those who are objectiing are simply reacting negatively to
change, not realizing that it very clearly is a change for the better
which still gets them exactly what they wanted with Fcc-first
behavior, as the desire to do that went into that decision. That should
be clear to anyone who carefully read the discussion.

More code, more config variables, are inherently bad.  They increase
the burden of management of the code and the probgram, and increase
the learning curve for developers and for users.  A single variable is
obviously only a tiny marginal burden, but when the development
community does not actively resist the urge to add one for every
little triviality, you end up with hundreds of unnecessary such
things increasing complexity, the maintenance burden, the learning
curve, etc..  We have seen over the years that they can cause bugs
where they can interact in unexpected ways, breaking things.

TBH I think (and have long thought) Mutt already has way, way too many
config variables, probably a significant portion of which really don't
provide that much value and should really be removed.

So yes, I will continue to apply some resistance to adding new ones,
as Thomas used to do, for all the same reasons he did.  There should
be a significant positive change in Mutt that is provided by a new
config variable, to counteract that inherent negative, before adding
it is even considered, and in my estimation this one provides only
negative.  But I am (sadly) just rehashing the conversation that went
into the original decision to implement the current behavior in the
first place. :(

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20190612/85d0127e/attachment.asc>