bug#28008: 25.2; Resume kmacro definition errors C-u C-u <F3>

[Allen Li]

On Fri, Aug 11, 2017 at 5:41 AM, Tino Calancha <tino.calancha@gmail.com> wrote:
>  ** Patch 1 always save the macro in `last-kbd-macro' after an error or 'C-g'.
>     Then, A. B. and D.2 behaves similarly.
>
>  ** Patch 2 adds a new variable `last-aborted-kbd-macro': it saves the partial
>     macro there after an error or 'C-g'.  Called `start-kbd-macro' with
>     APPEND non-nil offers to append on `last-aborted-kbd-macro'; possible 
> answers
>     are 'yes', 'no' or 'del' (i.e., append on `last-aborted-kbd-macro' after 
> delete
>     its last character).
>
>     This is not backward compatible; for instance, the snippets A, B above 
> won't be
>     saved in `last-kbd-macro' (currently they do).
>     It's more tidy; it separates 'good macros', i.e. those ended after
>     'F4' or 'C-x )', from 'partial macros', i.e., those ended after an error 
> or 'C-g'.

I'm not the best qualified to comment on the patches themselves, but 2
sounds like the best solution except that it breaks backward
compatibility. However, I hypothesize that no one is relying on the
old behavior (that non-quit errors stop the macro recording and yet
save it).

On Fri, Aug 11, 2017 at 6:00 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> All these low-level changes just to support an obscure use case?  Is
> really worth the risk to break macros to cater to that?

I suspect that this bug is one of the reasons that this is an obscure
use case, i.e. that people don't use kmacros as often as they would
like to.  Humans make mistakes, and when they make mistakes that
translates to either an error or a C-g stopping the kmacro definition,
which makes it impractical to use kmacros in the current form.  If it
were easy to recover from an error during kmacro definition, I know I
would use them more.