emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Experimentally unbind M-o on the trunk


From: Matt Armstrong
Subject: Re: Experimentally unbind M-o on the trunk
Date: Thu, 11 Feb 2021 07:46:03 -0800

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Thu, 11 Feb 2021 11:55:29 +0700
>> Cc: Eli Zaretskii <eliz@gnu.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, 
>> "Alfred M. Szmidt" <ams@gnu.org>, 
>>      Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
>>      Emacs developers <emacs-devel@gnu.org>
>> 
>> > Case in point: if a command isn't bound to a key it doesn't show up in
>> > help, so there is this pressure to bind everything that could possibly
>> > be useful to some person some day to some key. What if instead help
>> > showed all the interactive commands provided by the mode? What if M-x
>> > were smarter about highlighting mode specific commands?
>> >
>> > Perhaps exploring these kinds of ideas would be useful.
>> 
>> The mechanism you’re describing is called a menu.
>> 
>> Case in point: In almost every GUI program that follows the CUA
>> guidelines, you can invoke the File | Open command by pressing Alt+F
>> O.
>
> The original suggestion was to make it easier to discover _unknown_
> commands, whereas your menu analogy talks about invoking a _known_
> command.  I don't see how this analogy helps, what did I miss?

I think GUI menus help with discovering unknown commands by showing you
a list of them by category. I use Emacs menus this way, usually with
major modes I am unfamiliar with. Newer GUIs let you search for menu
items too.

The ideas Drew talked about elsewhere in this thread are similar, but
can typically handle more commands without overwhelming the user with
the possibilities (which I think was one of his points).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]