GNU bug report logs -
#11506
24.1.50; "C-x z" ("repeat") no longer works correctly with M-x
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11506 in the body.
You can then email your comments to 11506 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11506; Package
emacs.
(Fri, 18 May 2012 07:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Miles Bader <miles <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 18 May 2012 07:10:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
It used to be (up until fairly recently, dunno the exact point at
which it changed) that "C-x z" would correctly repeat the previous
extended command; e.g. if you entered "M-x pwd RET", and then "C-x z",
the latter would re-invoke "pwd". This was very useful.
Now it no longer does this -- instead it just repeats "M-x", prompting
for a command. This is obviously far less useful behavior...
To repeat:
emacs -Q
M-x pwd RET
C-x z
You will just get the M-x prompt; in older versions, it would print
the output of "pwd" again.
Thanks,
-Miles
In GNU Emacs 24.1.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
of 2012-05-17 on catnip
Configured using:
`configure '--without-rsvg''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
ESC x r e p o r t - e m SPC b u g RET
Recent messages:
("emacs")
Loading term/xterm...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
--
Love is a snowmobile racing across the tundra. Suddenly it flips over,
pinning you underneath. At night the ice weasels come. --Nietzsche
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility.
(Sat, 02 Jun 2012 19:24:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Miles Bader <miles <at> gnu.org>:
bug acknowledged by developer.
(Sat, 02 Jun 2012 19:24:02 GMT)
Full text and
rfc822 format available.
Message #12 received at 11506-done <at> debbugs.gnu.org (full text, mbox):
> The problem is that the old execute-extended-command sets the
> real_this_command internal variable, which causes the Emacs command loop
> to record the command that was actually executed into real-last-command
> and last-repeatable-command.
Indeed.
> In other words, it's not just the fact that `C-x z' doesn't work
> properly. Moving execute-extended-command to Lisp produces a
> backward-incompatible change in the values of the real-last-command and
> last-repeatable-command variables for M-x. I suspect this may break
> things other than `C-x z'. I guess we could fix this by exposing
> real_this_command to Lisp too, but that kinda defeats the point of that
> variable...
I don't see why this would defeat anything. Clearly,
execute-extended-command demonstrates that there can be very good
reasons to change real-this-command.
I installed a change that does just that.
> Is there a strong rationale for moving execute-extended-command to Lisp,
> other than the general principle that we want as much functionality
> implemented Lisp as possible?
To me, an important part of moving code to Elisp is to make sure that it
*can* be implemented in Elisp (i.e. that some third-party package can
provide a new implementation of that functionality).
Stefan
Message #13 received at 11506-done <at> debbugs.gnu.org (full text, mbox):
> I don't see why this would defeat anything. Clearly,
> execute-extended-command demonstrates that there can be very good
> reasons to change real-this-command.
>
> > Is there a strong rationale for moving
> > execute-extended-command to Lisp, other than the general
> > principle that we want as much functionality implemented
> > Lisp as possible?
>
> To me, an important part of moving code to Elisp is to make
> sure that it *can* be implemented in Elisp (i.e. that some
> third-party package can provide a new implementation of that
> functionality).
FWIW, Icicles does just that. It defines a multi-command version of `e-e-c',
which has been in daily use for 7 years. So certainly it can be done.
Message #14 received at 11506-done <at> debbugs.gnu.org (full text, mbox):
> FWIW, Icicles does just that. It defines a multi-command version of `e-e-c',
> which has been in daily use for 7 years. So certainly it can be done.
But I strongly suspects that it suffers from the same problem w.r.t C-x z.
Stefan
Message #15 received at 11506-done <at> debbugs.gnu.org (full text, mbox):
> > FWIW, Icicles does just that. It defines a multi-command
> > version of `e-e-c'
>
> But I strongly suspects that it suffers from the same problem
> w.r.t C-x z.
I saw two problems mentioned here:
M-x pwd RET C-x z z z ...
M-x dired-other-window foobar RET C-x z toto
RET z titi RET z ...
The first is not a problem in Icicles.
The problem reported for the second was that when repeating the last command
entered, if that command prompted for input then when repeated it should prompt
again but doesn't.
In Icicles, the `dired-other-window' example has the same problem: there is no
prompt for repetitions - the same dir is used repeatedly.
But if the command-name typed is instead `icicle-dired-other-window' then you
are prompted each time you hit `z' (with `default-directory' from the current
dir, i.e., the last Dired buffer created). The difference here is that
`i-d-o-w' does the prompting in the command body - the command has no arguments.
It works if you just hit `RET' at each such prompt from `z' for a directory.
However, if you type a different dir name at the prompt, then that breaks the
repeating. I guess this is because the minibuffer editing is taken as using a
different command.
So you are correct that `icicle-execute-extended-command' does not play with
`repeat' quite the same way as the C command `execute-extended-command'.
Message #16 received at 11506-done <at> debbugs.gnu.org (full text, mbox):
> I saw two problems mentioned here:
> M-x pwd RET C-x z z z ...
[...]
> The first is not a problem in Icicles.
So, how does Icicle solve it? Did you change C-x z?
Stefan
Message #17 received at 11506-done <at> debbugs.gnu.org (full text, mbox):
> > M-x pwd RET C-x z z z ...
> > The first is not a problem in Icicles.
>
> So, how does Icicle solve it? Did you change C-x z?
No, I didn't change `C-x z' or anything associated with repeat.el.
I don't know what causes the problem (or the "solution"). ;-)
The code is here, in case someone more knowledgable about `e-e-c' or repeat.el
wants to take a look:
http://www.emacswiki.org/emacs/download/icicles-cmd1.el.
(That uses macro `icicle-define-command', which is defined here:
http://www.emacswiki.org/emacs/download/icicles-mac.el)
But I don't claim (or expect) that the code I use for this is a model for
anything.
The reason I defined `icicle-execute-extended-command' was not to move `e-e-c'
to Lisp but to define a multi-command version of it. In effect, that lets you
use any command (via `M-x') as a multi-command.
(A multi-command just lets you act multiple times on multiple completion
candidates in the same command invocation. In this case, the candidates are
command names.)
This page describes `i-e-e-c' and its use:
http://www.emacswiki.org/emacs/Icicles_-_Multi_M-x
And this page describes its implementation:
http://www.emacswiki.org/emacs/Icicles_-_Defining_Multi_M-x
Anyway, as I mentioned, it is only a partial solution to the problems mentioned
in this thread.
The second problem remains, in two senses: (1) When the command to be repeated
expects an argument entered by the user (minibuffer input), the `C-x z z' does
not re-prompt. (2) If the command body (not the `interactive' spec) prompts for
input, and the user types or edits the minibuffer input, that breaks repetition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11506; Package
emacs.
(Mon, 04 Jun 2012 13:51:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 11506 <at> debbugs.gnu.org (full text, mbox):
Is there a problem with the automatic mailing of bug-thread messages, or is
there perhaps a problem with my mail server?
I sent two messages to this bug thread, and never received those mails from the
bug list. But they showed up on the archive site OK:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11506#15
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11506#17
Similarly, I received Stefan's reply to the first of these directly from him,
but I did not receive his message from the bug address.
If there is a mail problem at the Emacs BUGS end, is it perhaps only for the
<N>-done <at> debbugs.gnu.org address? If so, can that please be fixed? Whatever
discussion continues in a bug thread should be echoed to the bug mailing list,
no?
If not, I will no doubt have to manually remove "-done" from the cc address from
now on (or else add the address without "-done", in addition to "-done").
Users do not pay a lot of attention to the cc addresses when they hit `Reply
All'. This bug server automatically changes the address from
<N>@debbugs.gnu.org to <N>-done <at> debbugs.gnu.org, which is arguably not very user
friendly to begin with (changing recipient lists is not a great idea).
If we cannot figure out a better way to handle routing/classifying messages than
simply changing addresses, too bad. But can't we at least continue to echo the
discussion to <N>@debbugs.gnu.org (as well as cc or bcc it to
<N>-done <at> debbugs.gnu.org), so that readers of the thread receive the message?
The classification of a bug is not the same thing as the end of the discussion
of it.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 03 Jul 2012 11:24:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 350 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.