Re: Another bug with the macro counter

[Luc Teirlinck]

Your alternate patch seems OK, but I would make three changes to it.

First one: 

   + (defun kmacro-keyboard-quit ()
   +    (or kmacro-appending-p
   +        (kmacro-ring-empty-p)
   +        (kmacro-pop-ring))
   +    (setq kmacro-appending-p nil))

As you may already have pointed out yourself, you actually need:

   + (defun kmacro-keyboard-quit ()
   +    (or (not defining-kbd-macro)
            kmacro-appending-p
   +        (kmacro-ring-empty-p)
   +        (kmacro-pop-ring))
   +    (setq kmacro-appending-p nil))

The second one is that I would rename kmacro-appending-p to
kmacro-appending-flag.

>From `(elisp)Tips for Defining':

`...-flag'
     The value is significant only as to whether it is `nil' or not.

The `-p' convention is for functions. 

The third one is that I would keep the docstring I gave for
kmacro-appending-flag:

  "Non-nil when appending to a keyboard macro definition.
The value is nil when defining a new keyboard macro.
In other situations, the value is undefined."

The `(setq kmacro-appending-p nil)' is not sufficient to guarantee
that kmacro-appending-p will be nil outside a macro definition.

There are two reasons to quit inside a keyboard macro.

The first, in my usage by far the most common, is that you start
defining a macro and then mess it up.  You do C-g while Emacs is
waiting for keyboard input to get rid of the erroneous macro.
Currently that duplicates the last correct keyboard macro in a
confusing way.  This is the situation we are trying to correct.

The second is that a function called during the keyboard macro
definition takes a huge amount of time and the user quits to regain
control.  In this situation, `keyboard-quit' is not called and the
quit is handled by QUIT.  Now the C-g terminates the macro definition
without becoming part of it, just like C-x ).  The new macro is likely
to be useless.  Unlike in the first case, the user can not but notice
what happened and hence can remove the macro with C-x C-k C-d.  This
situation remains unchanged after either your or my patch.  If this
situation happens while appending to a keyboard macro, then
kmacro-appending-p will remain t, even though no macro is being defined.
I could give a concrete example if desired.

Sincerely,

Luc.