Macros don't work in Dired
deja8501
Since noone was able to answer my question in gnu.emacs.help I think
it must be a bug.
Here's the description:
If I bind F6 to "m"
(global-set-key (kbd "<f6>") "m")
and press f6 in a Dired buffer then the current file is marked, just
like when I press "m".
If I bind F6 to "R"
(global-set-key (kbd "<f6>") "R")
and press f6 in a Dired buffer then nothing happens, unlike when I
press simply "R" (rename file).
It's GNU Emacs 20.7.2 (sparc-sun-solaris2.6, X toolkit) of Fri Oct 13
2000.
Tom
Eli Zaretskii
>
> If I bind F6 to "m"
>
> (global-set-key (kbd "<f6>") "m")
>
> and press f6 in a Dired buffer then the current file is marked, just
> like when I press "m".
>
> If I bind F6 to "R"
>
> (global-set-key (kbd "<f6>") "R")
>
> and press f6 in a Dired buffer then nothing happens, unlike when I
> press simply "R" (rename file).
I think this is expected behavior: any command that asks the user for input
will ``not work'' in the same way as "R" didn't, if you bind a key to it via
a keyboard macro. Commands that don't ask for input will work. "R" asks
for the new name of the file, so it doesn't work, "m" doesn't ask anything,
so it does work.
You can get a hint as to what's going on if you look in the *Messages*
buffer after you press F6. There you will see that the binding actually
worked, and the command was invoked, but it signaled an error and did
nothing. To see why did it do nothing, press F6 and immediately after that
press ?.
What happens is this: you bind F6 to a keyboard macro which is supposed to
invoke the command that renames the file. When the keyboard macro runs, it
expects to find _all_ of its input, including any input required by the
commands it invokes, as part of the macro text. This is because a keyboard
macro works by effectively redirecting the input stream to the macro.
So, when dired-do-rename, the command bound to `R', asks for a new file
name, the response is read from the macro. But there's nothing in your
keyboard macro after the `R', so dired-do-rename behaves as if the user
typed RET to the prompt for the new name. A RET means you accept the
default file name offered as part of the prompt. But the default is
identical to the original file name, so you are asking dired-do-rename to
rename a file into itself, which is not allowed. Consequently,
dired-do-rename prints an error message (which only goes to *Messages*,
since we are in a keyboard macro), and does nothing.
The morale? Don't bind keys to keyboard macros which run commands that ask
for input. In this case, you can have what you want if you say something
like this:
(global-set-key [f6] 'dired-do-rename)
(Actually, you probably don't want this binding to be global, but I didn't
want to change your example too much, lest that obscures the real issue.)
deja8501
>
> The morale? Don't bind keys to keyboard macros which run commands that ask
> for input. In this case, you can have what you want if you say something
> like this:
>
Thank you for taking the time and giving a detailed answer to my
question. I don't remember reading in the documentation that keyboard
macros cannot run commands that ask for input, but I'm going to check
it.
-Tom
Eli Zaretskii
On 10 Aug 2001, deja8501 wrote:
> I don't remember reading in the documentation that keyboard
> macros cannot run commands that ask for input, but I'm going to check
> it.
It wasn't documented, but it will be in the next release. Thanks for
pointing this out.
Eli Zaretskii
> Newsgroups: gnu.emacs.bug
> Date: 17 Aug 2001 10:54:21 -0400
>
> >> I don't remember reading in the documentation that keyboard
> >> macros cannot run commands that ask for input, but I'm going to check
> >> it.
> > It wasn't documented, but it will be in the next release. Thanks for
> > pointing this out.
>
> a keyboard macro, when the end of the macro is reached, the input
> should automatically be redirected to the keyboard, so that
> a macro such as "R" works correctly.
I don't mind making this change, if no one else objects. But until we
do, the current behavior should be documented, I think.
deja8501
> for input.
You say that when running a macro, all input must be available. I
think this might not be what the user expects.
I recently implemented a GUI event record/playback application which
is quite similar to a macro. The recorder records every input event
and when playing back, it inserts the events one by one into the event
queue. After inserting an event, the recorder waits until every
generated event is processed and then it inserts the next event into
the loop.
This way there is no difference between user input and playing back
recorded event sequences. My original bug report was sent because I
thought that the inability to record incomplete event sequences (when
not all input is available for a function invoked by a macro) is a
bug, that is I cannot record a macro for e.g. Dired which offers a
default file name when renaming ("Rbackup" or something like that). (I
know that it probably could be done with hooks, but recording a macro
is much more simple).
I don't know the implementation of the Emacs macro facility, but I
think this behavior should be provided as an option if possible.
What do you think?
Richard Stallman
It might be an improvement, but it is not a trivial change, so now
is not the right time for it.
Eli Zaretskii
> Newsgroups: gnu.emacs.bug
> Date: 18 Aug 2001 09:15:56 -0700
>
> This way there is no difference between user input and playing back
> recorded event sequences. My original bug report was sent because I
> thought that the inability to record incomplete event sequences (when
> not all input is available for a function invoked by a macro) is a
> bug, that is I cannot record a macro for e.g. Dired which offers a
> default file name when renaming ("Rbackup" or something like that). (I
> know that it probably could be done with hooks, but recording a macro
> is much more simple).
As others wrote, it should probably be possible to extend the macros
so that when the macro ends, input is switched back to the normal
source. But this will only handle cases where the missing input is
something required as the last thing in the macro playback.
deja8501
> As others wrote, it should probably be possible to extend the macros
> so that when the macro ends, input is switched back to the normal
> source. But this will only handle cases where the missing input is
> something required as the last thing in the macro playback.
Yes, but I think it could be useful nevertheless if it's not too hard
to implement. It would make more sense from the user's point of view
if a macro would not abort in case of incomplete input, but rather
keep processing until possible and then leave it to the user to
provide the remaining input.
Implementing something with hooks is not always trivial. In case of my
example (offer a default filename when renaming in Dired, but only for
renaming, not for copying, etc.) implementing it with a macro is much
more simple than hacking advices for dired functions.
If I'm not mistaken modifying macro behavior like this would be
backward compatible and it would broaden the possibilities of macro
usage, making it more useful for novices who are not used to lisp
hacking.
Stefan Monnier
>
> It might be an improvement, but it is not a trivial change, so now
> is not the right time for it.
I would agree. But if we agree that the current behavior is undesirable
and should be changed, I think it would be wrong to document it.
Stefan