order of sending mail and saving to fcc

[Kevin J. McCarthy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20190612/2009ef10/attachment.asc>