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.
pgpN7n_ZBZN_z.pgp
Description: PGP signature
