order of sending mail and saving to fcc
mutt at raf.org
mutt at raf.org
Tue Jun 11 23:51:02 UTC 2019
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
More information about the Mutt-users
mailing list