Re: master 927b885 1/3: Disable filtering of commands in M-x completion

[Stefan Kangas]

eliz@gnu.org (Eli Zaretskii) writes:

> branch: master
> commit 927b88571cebb4f64aca360fbfa5d15a1f922ad6
> Author: Eli Zaretskii <eliz@gnu.org>
> Commit: Eli Zaretskii <eliz@gnu.org>
>
>     Disable filtering of commands in M-x completion
>
>     This makes the default behavior like it was before:
>     M-x completion doesn't filter out any commands.  To
>     have commands filtered based on their relevance to the
>     current buffer's modes, customize the option
>     'read-extended-command-predicate' to call
>     'command-completion-default-include-p'.

I can understand this decision for Emacs 28, but hope that we can
consider enabling it by default in Emacs 29.  (I would have preferred it
as the default in Emacs 28, but I can see the benefit in having a period
to let the feature stabilize and mature a bit first.)

I understand that sometimes a package developer will get filtering wrong
(i.e. a bug), and that at other times the user will know best if a
command is relevant or not.  I would expect this to overwhelmingly not
be the most common case.  But even if I am right about that, it is still
important that we get this situation right.

I think we should take one of the below actions:

a) Add a key to show the unfiltered list of matches in `M-x'.
   (We could use any key, but how about just using `M-x M-x' to show the
   unfiltered list?  It would affect recursive minibuffers, but we could
   just require a third `M-x' for that.)

b) Add a new command, e.g. on `C-x x x', that always acts like the old
   `M-x'.

c) Both.

And then we should consider making this feature the default, preferably
already in Emacs 28 but otherwise in Emacs 29.

Here is why:

I have never understood why Emacs suggests commands for execution in a
context where they will obviously fail.  I think this is a glaring
deficiency in our default UI -- you are proposed useless commands (that
won't work there, will screw up your buffer, etc.).  No longer doing
that is in my view a big step forward for Emacs usability.

Having this feature on provides additional safety that is most sorely
needed by "regular" users.  It will also make it easier to learn Emacs,
as there is less intimidating, often useless cruft to filter through.

Finding the correct command, often even a relevant one, was something I
personally struggled a lot with when I started out with Emacs.  My own
conclusion was that `M-x' was often practically useless as a discovery
mechanism.  This of course largely depends on what you are trying to do,
but consider finding a relevant Gnus command using `M-x'... not fun.

Finally, I note that Emacs is *not* more powerful because users can say
`M-x mwheel-scroll' -- it just has a lower signal to noise ratio.[1]

OTOH, it seems to me that the target audience for disabling this feature
is (or will be) mostly "hardcore"/"veteran"/"advanced" users who are
very used to and like the old behavior.

>From the discussions we've had so far, it is my understanding that some
like to use it for searching for and discovering commands.  That is fine
and valid, and reason for having an option to opt-out of this behavior.
(I also think we should add a `describe-command' to try to better cover
this use-case.)

Footnotes:
[1] Some modes are prudent in saying:

       (unless (derived-p 'foo-mode) (user-error "Nope"))

     I think up until now this has often been the right and safe thing
     to do, but it has unfortunately been severely underused.  Yet it
     still has the deficiency that the command will show up in 'M-x`,
     and it provides no fire-escape.