bug: "C-x z" ("repeat") no longer works correctly with M-x

bug: "C-x z" ("repeat") no longer works correctly with M-x

[Miles Bader]

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

Thanks,

-Miles

-- 
春風の　穏やかな波　草を弾く
春草の　穏やかな波　風を惹く

Re: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

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

This is due to the reimplementation of execute-extended-command in
r108080.  Aaron, could you please look into a fix?  Thanks.

Re: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Aaron S. Hawley]

On 5/29/12, Chong Yidong <cyd@gnu.org> wrote:
> Miles Bader <miles@gnu.org> writes:
>
>> 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...
>
> This is due to the reimplementation of execute-extended-command in
> r108080.  Aaron, could you please look into a fix?  Thanks.

I had given a more literal translation of the C command to the
gnu-emacs-sources mailing list back in March.  Stefan and I discussed
it but hadn't run across this issue with repeat.  He later made some
modifications to my submission and committed it in May.  I have only
now run it and can confirm this bug with repeat.  I'm not sure what's
causing it though, but found the following fixes it.  Again, I'm not
sure why.  Nor am I sure if it's a wholly appropriate fix.

--- simple.el	2012-05-29 07:21:45.000000000 -0400
+++ simple.el	2012-05-29 14:30:41.942777900 -0400
@@ -1373,7 +1373,7 @@

 Noninteractively, the argument PREFIXARG is the prefix argument to
 give to the command you invoke, if it asks for an argument."
-  (interactive (list current-prefix-arg (read-extended-command)))
+  (interactive "P")
   ;; Emacs<24 calling-convention was with a single `prefixarg' argument.
   (if (null command-name) (setq command-name (read-extended-command)))
   (let* ((function (and (stringp command-name) (intern-soft command-name)))

Re: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Chong Yidong]

"Aaron S. Hawley" <aaron.s.hawley@gmail.com> writes:

> I had given a more literal translation of the C command to the
> gnu-emacs-sources mailing list back in March.  Stefan and I discussed
> it but hadn't run across this issue with repeat.  He later made some
> modifications to my submission and committed it in May.  I have only
> now run it and can confirm this bug with repeat.  I'm not sure what's
> causing it though, but found the following fixes it.  Again, I'm not
> sure why.  Nor am I sure if it's a wholly appropriate fix.

No, tweaking the interactive spec does not really fix the problem.

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

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?  If not, it may not be worth making this
change, at least in Emacs 24.2, due to the risk of gratuitous
incompatibilities.

Re: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Miles Bader]

FWIW, my current workaround for this issue is to do "C-x ESC ESC RET"
to repeat the M-x the first time, and then use "C-x z" to further
repeat _that_ (since hitting "z" repeatedly is much easier).

The behavior isn't precisely the same as "C-x z" after M-x used to
exhibit, in that if the M-x command prompts for arguments, this will
repeat the command using the arguments supplied the first time,
whereas the old behavior was to re-prompt the user for each argument
(although the command itself was remembered).

My impression so far is that the behavior of this workaround is
actually more convenient, and when "C-x z" is fixed, I kinda wish it
would actually work this way instead, ... not sure how this fits into
the current discussion, but ... maybe it might suggest a mechanism for
doing this?

Thanks,

-miles

-- 
「すっごい」と呟いてる。「へんてこなもんばっかり」
「そんなにへんてこ？」
「へんてこへんてこ」
そう言われると見たくなってしまう。

bug#11506: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Stefan Monnier]

> 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

Re: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Aaron S. Hawley]

On 6/2/12, Chong Yidong <cyd@gnu.org> wrote:
> "Aaron S. Hawley" <aaron.s.hawley@gmail.com> writes:
>
>> I had given a more literal translation of the C command to the
>> gnu-emacs-sources mailing list back in March.  Stefan and I discussed
>> it but hadn't run across this issue with repeat.  He later made some
>> modifications to my submission and committed it in May.  I have only
>> now run it and can confirm this bug with repeat.  I'm not sure what's
>> causing it though, but found the following fixes it.  Again, I'm not
>> sure why.  Nor am I sure if it's a wholly appropriate fix.
>
> No, tweaking the interactive spec does not really fix the problem.
>
> 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...
>
> 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?  If not, it may not be worth making this
> change, at least in Emacs 24.2, due to the risk of gratuitous
> incompatibilities.

I agree, it's not worth it if things break.  As I wrote to
gnu-emacs-sources, I've been using a Lisp version of M-x for several
years.  Obviously, I ran into issues when I first tried writing the
code, but haven't run into any issues since.  I am a big user of
repeat and repeat-complex-command and keyboard macros.  I think it's
possible to get this Lisp version to work as well as the C version.

I understand your concern about real_this_command in command_loop and
call-interactively.  However, it's not clear if there's any reason for
it for M-x.  I'd be interested to know if there other issues.  Perhaps
the timeline of 24.2 won't allow for it?

I've made sure repeat works if M-x is a mouse event by adding it to
the tool-bar or the menu-bar.

(define-key menu-bar-tools-menu [m-x]
  `(menu-item ,(purecopy "M-x") execute-extended-command
	      :enable (menu-bar-non-minibuffer-window-p)
	      :help ,(purecopy "Execute extended command")))

(tool-bar-add-item-from-menu 'execute-extended-command "mpc/add"
			     nil :label "Execute extended command"
			     :vert-only t)

I do suggest the following fixes to rework Stefan's revision,
including the change to the interactive spec.  Some of it is white
space changes and a comment that no longer applies.

2012-05-29  Aaron S. Hawley  <aaron.s.hawley@gmail.com>

        * simple.el (execute-extended-command): Reading command-name in
        interactive form breaks the repeat command.  Improve error message
        for empty command-name.

--- simple.el	2012-05-29 08:21:45.000000000 -0400
+++ simple.el	2012-05-29 18:46:04.836717200 -0400
@@ -1373,17 +1373,20 @@

 Noninteractively, the argument PREFIXARG is the prefix argument to
 give to the command you invoke, if it asks for an argument."
-  (interactive (list current-prefix-arg (read-extended-command)))
+  (interactive "P")
   ;; Emacs<24 calling-convention was with a single `prefixarg' argument.
-  (if (null command-name) (setq command-name (read-extended-command)))
+  (when (null command-name)
+    ;; Could be in `interactive' as well, but it breaks `repeat'.
+    (setq command-name (read-extended-command)))
   (let* ((function (and (stringp command-name) (intern-soft command-name)))
          (binding (and suggest-key-bindings
-                        (not executing-kbd-macro)
-                        (where-is-internal function overriding-local-map t))))
+                       (not executing-kbd-macro)
+                       (where-is-internal function overriding-local-map t))))
+    (when (and (stringp command-name)
+               (= 0 (length command-name)))
+      (error "No command name given"))
     (unless (commandp function)
       (error "`%s' is not a valid command name" command-name))
-    ;; Set this_command_keys to the concatenation of saved-keys and
-    ;; function, followed by a RET.
     (setq this-command function)
     (let ((prefix-arg prefixarg))
       (command-execute function 'record))

-- 
In general, we reserve the right to have a poor
memory--the computer, however, is supposed to
remember!  Poor computer.  -- Guy Lewis Steele Jr.

bug#11506: bug: "C-x z" ("repeat") no longer works correctly with M-x

[Drew Adams]

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