Skip to content

Draft: Make macro interpretation more robust by aborting at the first inconsistency with the current context

Samuel Hym requested to merge rustyne/mutt:strict-macros-v1 into master

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.

Merge request reports