--- Begin Message ---
|
Subject: |
M-x should prompt with function under cursor as default |
|
Date: |
Wed, 04 Jun 2008 06:53:40 +0800 |
Today I was reading a message where this guy said
> FWIW, there are also `customize-apropos' and `customize-apropos-options'.
So I put the cursor upon the word customize-apropos-options and typed M-x,
and would you believe I had to help emacs figure out what I wanted to do,
which was of course to type M-x customize-apropos-options.
(Yes, with the assistance of TAB.)
Compare C-h f (describe-function) with the cursor in that position. It
knows what to do: prompt with what it finds under the cursor.
P.S., I cannot help with patches because I am too busy reporting bugs
I encounter in the surface interface, which I am much better at doing
than coding. Each person has things they are better at doing.
--- 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 ---