* Derek Martin <inva...@pizzashack.org> [2019-06-11 12:36 -0500]: > On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote: > > In the event that send fails, the local copy is essential for a resend > > attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any > > scenario in which mutt should risk inability to write that Fcc, through a > > hang-up or conniption during sending. > > This argument seems like complete nonsense to me... if the send > fails, you're left back at the compose screen. If by some > unbelievable coincidence the send fails AND you lose power before you > can do something about it, this is NO DIFFERENT than if the power went > out just before you finished composing the message.
It is different. In one case nobody has my mail. In the other case the recipient might have it, but the sender does not. > It's not your > mail client's job to protect you from every conceibable system failure > which might cause data loss, nor should it be. Of course it is not its job. If my computer melts to a blob of something, that is not mutt's problem. But it is mutt's job to make it easier (or even possible without arcane workarounds) to avoid more or less simple problems. Diskless workstations loosing their connectivity at the worst moment. Crashing systems. ... > And for every other > case, the current behavior is the far superior one because it can not > mislead you into thinking you sent a message you did not, and does not > lead to the various encoding issues Kevin mentioned separately. It is quite easy to have a setup, where I can verify if the mail was sent if there is any doubt. The new behavior does create a situation that makes it much more likely to create a situation where I have to ask e.g. a client for a mail I sent to him. That would be quite embarrasing without some good explanation (like a major event, like a house which burned down). > But also, just because the message failed to send, your ideas and the > impetus for writing them down didn't vanish. Your brain is the > back-up. Ahm. No. Any temporary information copied into the mail is just not in my brain. Anything where the exact wording is important cannot be reproduced (so the recipient gets two mails that are different, and the sender only knows one of them). > In the event that the message in question is the unusual > combination of lengthy, complex, and important enough that the pain of > re-composing it from scratch is somehow prohibitive, then you damn > well better be composing it using a word processor that takes frequent > snapshots of your document as you compose, and then sending it as an > attachment (or as a link, or by doing a text conversion, or... > whatever)--not relying on your mail client to preserve it. I'm relying on my mail client, that it safely stores a message of every message sent. > And by the > way even then, you can't guarantee 100% that you won't lose the data. > Your hard disk could explode, say due to a lightning strike. No > software can't protect you from that. At a certain point such > considerations become completely ridiculous. Yeah. But that is no reason to not protect from things it can protect me easily from by just storing the message before sending it. I do not want to protect mutt my mail from a supernova in my hard disk. I consider it quite absurd to use such an argument: "Why should I ever call fsync? The computer may be struck by lightning and might get lost completely." > 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. 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. Nicolas
