Draft: Make macro interpretation more robust by aborting at the first inconsistency with the current context
During the interpretation of a macro, if we end up in some state where the content of the macro does not apply (because it uses a key that does not match any of the possible choices of a prompt, for instance), the current behaviour is to skip that key and keep going interpreting the macro. These patches propose a safest behaviour, aborting the macro when that happens.
I’ve been bitten by this bug quite a few times, where something unexpected happens in the middle of a complex macro, and ended up with files with silly names created (no mail lost hopefully, but it could have happened).
Here is a sample muttrc
, simplified from my configuration, that shows the modification of behaviour:
set editor = "true"
set edit_headers
set autoedit
set noabort_unmodified
macro index F "<forward-message><enter-command> set postponed='=tmp'<enter><postpone-message>"
macro index G "<forward-message><show-version><postpone-message>"
When pressing F
on mails without attachments, this does what one hopes. On a mail with attachments, since $forward_attachments
defaults to ask-yes
, in an English locale, <enter-command> set postpo
gets dropped (beeping on the way), n
answers the question, e
spawns true
again, d
changes the description to ='=tmp'
and the message gets postponed in the default mailbox. Quite far from the intended meaning of the macro.
This is a draft, with the following points open:
- is -2 the proper return value for
km_dokey
? - they are other prompts where aborting the macro if we are running one would probably make sense,
- it would be good to have testing macros for all the branches running into abort.