[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another bug with the macro counter
From: |
Luc Teirlinck |
Subject: |
Re: Another bug with the macro counter |
Date: |
Sun, 31 Oct 2004 15:01:05 -0600 (CST) |
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.
- Re: Another bug with the macro counter, (continued)
- Re: Another bug with the macro counter, Luc Teirlinck, 2004/10/30
- Re: Another bug with the macro counter, Luc Teirlinck, 2004/10/30
- Re: Another bug with the macro counter, Kim F. Storm, 2004/10/30
- Re: Another bug with the macro counter, Luc Teirlinck, 2004/10/30
- Re: Another bug with the macro counter, Luc Teirlinck, 2004/10/30
- Re: Another bug with the macro counter, Kim F. Storm, 2004/10/30
- Re: Another bug with the macro counter,
Luc Teirlinck <=
- Re: Another bug with the macro counter, Kim F. Storm, 2004/10/31
- Re: Another bug with the macro counter, Richard Stallman, 2004/10/31