--- Begin Message ---
|
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#5364: 23.1.91; execute-extended-command should do like FFAP |
|
Date: |
Mon, 23 Aug 2010 00:32:29 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) |
> 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.
--- End Message ---