invert the "abort-noattach" question

[Daan van Rossum]

Dear mutt devs,

The abort_noattach feature that was added in mutt 1.10 is useful but counter-intuitive. You expect a "do you wish to continue" question and automatically answer "N", which results in accidentally sending the email without attachment.

I learned to be really careful with this question now, but wondered if it is a good idea (or even still possible) to invert this question so other users don't run into this as well.

Best, Daan

[Kevin J. McCarthy]

Post by Daan van Rossum
The abort_noattach feature that was added in mutt 1.10 is useful but
counter-intuitive. You expect a "do you wish to continue" question
and automatically answer "N", which results in accidentally sending
the email without attachment.
I learned to be really careful with this question now, but wondered if
it is a good idea (or even still possible) to invert this question so
other users don't run into this as well.

Unfortunately, there is more precedence to the feature than the 1.10
release. It was pulled from a Debian patch, and has also been in
NeoMutt for a while. So, while I'm sympathetic, I think it would cause
more turmoil to reverse the behavior.

You do have a good point about the inconsistency with the prompts
though. Looking at other quadoptions it's split down the middle which
answer aborts potentially undesirable behavior:

With these you answer "yes" to stop:
abort_noattach
abort_nosubject
abort_unmodified
postpone

While with these you answer no:
delete
pop_delete
print
quit

The upside is the first four all have to do with message composition, so
generally choosing "yes" during message composition is the safe answer!

For your case, you may want to try setting $abort_noattach to "yes", and
then adding a 'Y' macro to override:

macro compose Y '<enter-command>set abort_noattach=no<enter>\
<send-message><enter-command>set abort_noattach=yes<enter>'

[Ian Collier]

Post by Daan van Rossum
abort_noattach
abort_nosubject
abort_unmodified
postpone

The postpone question is special because both answers stop.
In fact, if you quit accidentally and get asked the question
"Postpone this message? ([yes]/no):" then what you should never
do is answer "no" on the grounds that you want to continue editing
the message instead of postponing it, because that will actually
discard the message.

imc

[Patrick Shanahan]

Post by Ian Collier

Post by Daan van Rossum
abort_noattach
abort_nosubject
abort_unmodified
postpone

The postpone question is special because both answers stop.
In fact, if you quit accidentally and get asked the question
"Postpone this message? ([yes]/no):" then what you should never
do is answer "no" on the grounds that you want to continue editing
the message instead of postponing it, because that will actually
discard the message.

yes, you *should* <ctrl><g>
to abort the questioned action

you cannot expect mutt to know what or when you make an unintended action.

[Cameron Simpson]

Post by Patrick Shanahan

Post by Ian Collier

Post by Daan van Rossum
abort_noattach
abort_nosubject
abort_unmodified
postpone

The postpone question is special because both answers stop.
In fact, if you quit accidentally and get asked the question
"Postpone this message? ([yes]/no):" then what you should never
do is answer "no" on the grounds that you want to continue editing
the message instead of postponing it, because that will actually
discard the message.

yes, you *should* <ctrl><g>
to abort the questioned action
you cannot expect mutt to know what or when you make an unintended action.

No, but you can and often should make the default answers to questions
(a) not throw data away and (b) more generally, not do harm.

On that basis: postpone should default to yes.

Now, on the premise of Heuer's Law:

If it can't be turned off, it's not a feature. - Karl Heuer

the settings of postpone and abort_noattach etc should constitute the
defaults, and mutt's _unconfigured_ state should set these to "do no
harm, lose no data" defaults.

My personal practice is that (a) defaults should do the least harm and
that (b) the default answer should be "no" or "false" consistently, and
options construed such that "no" or "false" means the safer choice.

As an example, when I write Python functions with optional Boolean
parameters, those parameters _always_ default to False, and the
parameter's name is so defined that False is the safer (or less weird,
when "safer" is less well defined) mode.

Cheers,
Cameron Simpson <***@cskk.id.au>