On Tue, Jun 11, 2019 at 08:11:33PM +0200, Nicolas Rachinsky 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^) > > You might consider it wrong but I do not seem to be the only one > thinking the old order is the correct one.
The argument is really simple. The current solution solves your problem, and mine. Your solution solves only your problem. > Considering how often I heard other people swear because they lost > some sent mail, because their MUA crashed after sending and before > storing it, this does just seem to be the wrong order. I've been on this list since ~1995, and I've certainly heard people express concern about the possibility of this, I can't say that complaints about it actually happening have been particiluarly common. To avoid going back and forth responding to quoted comments, I'll instead summarize the concerns. As best I can recall, there are 3: 1. If you DON'T save the message first, it is impossible to resend the message if sending fails. 2. If you DO save the message first, it can lead to misleading the user into thinking messages were sent, when they never were. 3. If you DO save the message first, it has negative repercussions in terms of cryptography, certain headers, etc. which will not be "correct" in the saved copy. Ignoring the fact that #1 is hogwash anyway, because you certainly can recreate a message that captures the sense of what you wrote the first time, even if it is not word-for-word identical, the current solution solves ALL of those concerns: 1. If sending fails, you are left at the compose menu, with a copy of your original message at the ready. This is already a rare occurence for most people. The most likely reason for sending to fail is you used an invalid address. Every mail client has means to prevent that from happening if you are sending to someone you've already interacted with (address book, Mutt aliases, LDAP lookup, etc.), excepting the case where a previously valid address suddenly is not. 2. In the extraordinarily unlikely event that sending fails, AND you have a power outage while you are sitting at the compose menu, you still have a copy of at the very least your message text, sitting in the temporary file Mutt was going to use to send the message. And let's be extremely clear: THIS IS UNBELIEVABLY UNLIKELY. But it can happen. 3. In the equally extraordinarily unlikely event you can not remember who you were going to send the message to, you can set edit_headers=yes and Mutt will copy the headers into the temporary file, so you will not lose those either. The notion is completely asinine, but it was raised as a concern, so, there you go. 4. Mutt will update encryption and any heaers added or changed by sending before it is copied to Fcc, so the file on disk will be as accurate a copy of your message as possible. 5. The Fcc copy will be created only once the message is actually sent, so there is no misleading of the user to think the message was sent when in fact it was not. 6. In the event creating the Fcc copy fails, Mutt will prompt you what to do, giving you the opportunity to deal with it however you like. In the mean time, the temporary copy still exists on disk, in the event of non-catastrophic system failure at this point. 7. In the event of actual catastrophic system failure, none of these things will save you. Everyone appears to agree Mutt should not try to solve for this. So, all of your concerns are addressed by the current behavior. None of the concerns that brougnt this behavior into being are addressed by the behavior you want. The only logical conclusion then, which I now feel completely justified in saying, is that if you still want that behavior, YOU ARE SIMPLY WRONG. -- 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.
pgpwITz4RVDLQ.pgp
Description: PGP signature