On Tue, Jun 11, 2019 at 05:28:26PM -0500, Derek Martin wrote:
Obviously you don't need to listen to me
I do listen to you, Derek. The whole buffer pool migration is a result of your recurring prods, and I will continue to work on that, likely through the next couple major releases.
I also pay attention to other people's viewpoints, especially long time users.
Technically, the arguments for post-send fcc are fine. I believe that, barring the most extreme cases, the pieces are there to prevent major loss (albeit sometimes with $tmpdir diving if mutt was killed). It's now the default, and I don't have an intention of changing that.
It's easy to conclude that objections to the change are overly paranoid or irrational, but Mutt users in general *really* *care* about email. My interest is in empowering them, to the best of my ability. I didn't make the change out of a desire to ruin their workflow, but moreso due to the technical problems of manipulating the message prior to sending.
It's evident, to me, that this change is extremely distressing to at least a subset of our users, who really care about having the message in their Fcc box before it gets sent out, regardless of the issues.
I can't give them exactly the old behavior, but I can _easily_ give them something approaching it.
Mutt already has tons of config vars, and Mutt is already a beast to learn how to configure
I agree. However, to counter that I've tried to use and extend existing prefix namespaces, and more descriptive (if sometimes verbose) names. $forward_attachments for a forwarding option; $crypt_ and $crypt_protected_headers_ prefixes for the new Protected Headers; $imap_qresync; $history_remove_dups, etc. The list grows longer, but in this way is (I hope) still possible to browse and understand what is changeable for a certain aspect of Mutt.
Regarding code complexity, the send code has already been simplified this release, partly because of the refactorings for the fcc-after change and Protected Headers introduction. I would even say it's starting to approach readability ;-). So, while I'm watchful for the proverbial straw on the camel's back, I'm still quite happy with the direction of the code and I'm not concerned about the impact of adding $fcc_before_send.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
