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: jidanni <at> jidanni.org
Subject: bug#355: closed (Re: bug#5364: 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 bug report

#5364: M-x should prompt with function under cursor as default

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 355 <at> debbugs.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: 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.

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

From: jidanni <at> jidanni.org
To: bug-gnu-emacs <at> gnu.org
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.

Previous Next

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