"Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Lars Ingebrigtsen [2021-07-20 14:37 +0200] wrote: > >> writes: >> >>> Good idea, attaching a revised patch (which also adds two NEWS entries.) >> >> Sorry; I forgot all about this. I've now re-read and tested the patch, >> and it seems to work fine for me, so I've pushed it to Emacs 28. > > Thanks, but given the following file quit.el, which is distilled from > the Ivy package's batch-run test suite: > [...] > IOW, it's no longer possible to catch the quit around execute-kbd-macro. > I tried wrapping it in (catch 'exit ...) as well, but to no avail. > Surely it should always be possible to catch a quit condition from Lisp? > In order to make C-g from a minibuffer not abort kmacro execution, execute-kbd-macro was made to catch the minibuffer-quit condition, handle it with the default error handler (command-error-function) and continue with kmacro execution. In batch mode, this error handler kills Emacs with status 255. Please consider the attached patch, which avoids killing for the minibuffer-quit condition. However, even with this patch, slight change in behaviour still remains: - In Emacs 27, C-g in the minibuffer is bound to abort-recursive-edit which makes execute-kbd-macro signal an error (a quit). - In Emacs 28, C-g is bound to abort-minibuffers. This command will not make execute-kbd-macro signal any errors. I hope this change in default behaviour is acceptable, otherwise it wouldn't be possible to have C-g continue with kmacro execution. For test suites, you can get back the old behaviour with (define-key minibuffer-local-map "\C-g" #'abort-recursive-edit) Sorry for late reply, best regards.