Re: Current mode command discovery

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

>> Listing the irrelevant commands would only serve to confuse and overload
>> the user.
>
> For the way I use M-x, I absolutely need what you call "irrelevant"
> commands.  Suggesting that these "confuse and overload" me is not a nice
> thing to do.

How often do you need to consult a command about foo-mode while working
on a buffer with baz-mode ?

>> Those who insist on using M-x to discover things while working on
>> random buffers (something that seems quite bizarre to me, to be honest)
>> still can disable the filtering or, better, learn to use the Emacs help
>> system.
>
> Ditto for this paragraph.  My memory is imperfect, and that includes
> memory of command names.  I routinely find exact names from hazy half
> memories by typing in M-x, the bits I think I remember, the occasional
> asterisk, and hit the TAB key.  This works reasonably well.  And for this
> process, I don't want to have to switch to, or create a "relevant"
> buffer.  I will certainly be disabling this filtering.  As for learning
> to use the help system, that's hardly a serious suggestion.

Why using M-x is more convenient for you than using C-h a, C-h f or some
other facility?

I'm trying to understand the mindset of those like you that use M-x for
exploring features or remembering commands. I use M-x for both purposes
all the time, but almost always I want to do something with that
command, which implies that I'm working on a context where the command
that I'm interested on will pass the filter. Thus, the filtering is a
great improvement.

>> >> This would only be commands that have been marked for the current major
>> >> mode and any active minor modes, I guess?
>
>> > What about primitives? they are relevant in any mode.
>
>> Here I think that Lars is proposing an special command that just shows
>> those commands marked as related to the current active modes. Regular
>> M-x will still show the commands which are relevant in general, in
>> addition to the specific ones.
>
> There are around 11,380 commands in just the Emacs Lisp sources.  I'm not
> sure it's practical to classify that number of commands as relevant for
> all the scenarios the new feature is intended for.  It's a great deal of
> work.

Almost all commands fall into two categories: specific to some mode
(which means that they only work if the mode is active) or general. I
see no problem classifying the commands that way.

I'm skeptic about other uses for the filtering that were mentioned, such
as adding predicates that test if a region is active, etc. That looks as
anti-feature to me. There are times when a menu entry should be hidden
and times where it should be grayed out (inactive). Likewise, a command
should not be hidden when it is related to the current context but a
detail makes it inapplicable. Just allow it to be invoked and throw an
user-error informing the user about what's wrong.