GNU bug report logs - #5364
23.1.91; execute-extended-command should do like FFAP

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Juri Linkov <juri <at> jurta.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#5364: closed (23.1.91; execute-extended-command should do
 like FFAP)
Date: Sun, 22 Aug 2010 23:34:03 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 23 Aug 2010 00:32:29 +0100
with message-id <87wrriw7ea.fsf <at> mail.jurta.org>
and subject line Re: bug#5364: 23.1.91; execute-extended-command should do like FFAP
has caused the GNU bug report #5364,
regarding 23.1.91; execute-extended-command should do like FFAP
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
5364: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5364
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: jidanni <at> jidanni.org
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.91; execute-extended-command should do like FFAP
Date: Tue, 12 Jan 2010 20:52:23 +0800

OK, how would you execute this command that you see sitting in front of you?
(list-load-path-shadows)

I ended up doing <escape> x l i s t p <backspace>
- <escape> / <return>

That's because I am unable to just put the cursor on it and do M-x, as
for some reason execute-extended-command won't prompt me for it even now
these days. I recall the idea was rejected.

Would you put the cursor after it, and hit C-x C-e?
Well sorry. That will fire up the non interactive version, etc.
In GNU Emacs 23.1.91.1

[Message part 3 (message/rfc822, inline)]

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5364-done <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#5364: 23.1.91; execute-extended-command should do like FFAP
Date: Mon, 23 Aug 2010 00:32:29 +0100

> This patch moves interactive spec into Elisp and also implements
> the following task from comments in execute-extended-command:
>
>   /* This isn't strictly correct if execute-extended-command
>      is bound to anything else.  Perhaps it should use
>      this_command_keys?  */
>
> It uses `(key-description (this-single-command-keys))' to do this.

Actually, it occured to me that displaying a key other than "M-x"
in the prompt of `execute-extended-command' is too confusing.

For instance, in bindings.el `execute-extended-command' is bound to the
[menu] key.  When I accidentally type the <menu> key, the first reaction
is "What does this mean?!" because it's very strange to see the prompt
"<menu> " waiting for a command.  It looks like a beginning of a key
sequence for the main menu.  OTOH, a well-known prompt "M-x" means
it reads an extended command.  I've added a comment that explains
why "M-x" is better than anything else.

Also we should keep the current function signature of
`execute-extended-command' unchanged and not to add a new arg
for two reasons:

1. There are places in code that call `execute-extended-command'
with one argument.

2. Calling `read-extended-command' to read a command name should not be
in the `interactive' spec because it needs to remember the hourglass
status before reading a command name (using `hourglass_started'),
and restore the hourglass (using `start_hourglass') after that.

So I installed a patch that calls `read-extended-command'
in the middle of `execute-extended-command'.

Of course, moving the whole of `execute-extended-command' to Elisp
would be better but the main obstacle is the hourglass functions
that have no Elisp interface.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.