[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#11506: closed (24.1.50; "C-x z" ("repeat") no long

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11506: closed (24.1.50; "C-x z" ("repeat") no longer works correctly with M-x)
Date: Sat, 02 Jun 2012 19:24:02 +0000

Your message dated Sat, 02 Jun 2012 15:21:51 -0400
with message-id <address@hidden>
and subject line Re: bug: "C-x z" ("repeat") no longer works correctly with M-x
has caused the debbugs.gnu.org bug report #11506,
regarding 24.1.50; "C-x z" ("repeat") no longer works correctly with M-x
to be marked as done.

(If you believe you have received this mail in error, please contact

11506: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11506
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.1.50; "C-x z" ("repeat") no longer works correctly with M-x Date: Fri, 18 May 2012 16:09:22 +0900
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.



In GNU Emacs (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:
Loading term/xterm...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

(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

--- End Message ---
--- Begin Message --- Subject: Re: bug: "C-x z" ("repeat") no longer works correctly with M-x Date: Sat, 02 Jun 2012 15:21:51 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
> 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.


> 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).


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]