Derek Martin wrote: > On Tue, Jun 11, 2019 at 01:45:18PM -0700, Kevin J. McCarthy wrote: > > On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote: > > I've pushed a branch up to gitlab, kevin/fcc-before-send. It adds > > $fcc_before_send, default unset. > > Obviously you don't need to listen to me, but I do want to state for > the record that I'm opposed to this change going in. I'm sure a lot > of people will say, "Oh, it's just a config variable." Those > who've been paying attention will realize I've consistently argued > against new config variables by default, over the last 20+ years, and > I'll restate my unwavering reasoning for that here: > > Mutt already has tons of config vars, and Mutt is already a beast to > learn how to configure--I think it takes years for people to even > realize all the features Mutt has that are configurable, nevermind > getting a config that does all they want. As such, (I believe) adding > a new config variable is inherently bad, and should only be done when > the good of having the alternative behaviors outweighs that bad. Such > cases clearly exist, and in those cases I don't argue against them. > > This is not such a case. I believe I have demonstrated in my last > post in this thread, using sound logic, that the alternative behavior > is not only never an improvement for any of the stated concerns, but > inarguably worse for some of the relevant concerns, and as such clearly > does not outweigh the bad of making Mutt that much more unweildy to > understand and configre. Therefore, the change should not be > committed. > > -- > Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
I could be wrong (and I haven't read the patch so apologies if I'm being silly) but I think that this patch might be too simple. If all it does is perform the fcc before sending rather than after sending, then the message that it saves isn't the message that is subsequently sent (as explained earlier). While I personally think that the copy in the /tmp directory suffices in times of trouble (so far anyway), clearly not everyone agrees. However, I would expect such people to still want the actual message that is saved to be a true record of the message that was sent (taking into account the other fcc-related config options). At least, once it is successfully sent. So, if something like this config option were to go ahead, it should probably save the pre-sending version before sending and, when the sending succeeds, replace the pre-sending version of the message with the final version that was actually sent. Otherwise, the saved message is only appropriate for re-sending but not appropriate as a permanent record of what was sent. At least, that's the impression I get from reading this thread. But that sounds like messy behaviour if the pre-sending copy and the post-sending copy are in the same file. If the patch is as I imagine, the documentation should make it clear that turning the new config option on means that the messages that are saved are not identical to the messages as they were sent. Having the pre-sending copy in a separate file would help keep the code change simple but of course that will bring about yet another config option to supply the name of the additional file (like postponed). Another advantage of a separate file for messages-that-are-in-the-process-of-being-sent is that the presence of the file on disk is an indication of a failure to send since the file would be deleted or emptied when the post-sending copy is saved. Note that I'm not recommending these changes, just pointing out that using the new fcc_before_send shouldn't necessarily mean that the sent box is no longer a true record of what was sent. Again, apologies for wasting time if I've misunderstood things. I've used mutt for decades but I'm no expert on its internals. cheers, raf
