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

[Drew Adams]

> I think we should take one of the below actions:
> 
> a) Add a key to show the unfiltered list of matches in `M-x'.

Add a key _to_ filter, instead.  (I mentioned
that my own code provides several keys for
filtering according to different criteria.)

I think Lars proposed (also?) providing another
command, which people could use instead of (or
in addition to) the command bound by default to
`M-x'.

Users could bind that new command to keys.  We
could later decide whether it should have a key
binding by default, or whether it should take
over `M-x' by default.  All of that should be
decided after more user experience and after
discussion of the pros & cons (like the current
discussion, but with benefit of experience). 

> (We could use any key, but how about just 
> using `M-x M-x' to show the unfiltered list?

That would be a particularly bad key choice, for
the reason you mention next:

> It would affect recursive minibuffers, but we
> could just require a third `M-x' for that.)

We could "just"?  Why would we choose a key that
requires jumping through such extra hoops?  Why
would we choose a key that _otherwise_ makes
sense within `M-x'?

And this is only one kind of filtering, even for
command completions.  And command completions
are only one kind of completion.  More general
completion-filtering keys are what are called
for, in addition, perhaps to some command-specific
ones (e.g. some, like what's currently proposed,
that are for command completion).

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

What's the hurry?  Emacs has used `M-x' for 35+
years.  Suddenly this new shiny object is a MUST,
and needs to replace the longstanding behavior?

> Here is why:
> 
> I have never understood why Emacs suggests
> commands for execution in a context where they
> will obviously fail.

1. "Obviously fail" has recently been argued by
Lars and others as being an insufficient test.

2. People have explained why.  They've said how
it can be useful for `M-x' to suggest also
commands that might fail.

3. You haven't understood why.  OK.  And why
is that lack of understanding a reason why the
behavior should change ("Here is why")?

> I think this is a glaring deficiency in our
> default UI

Glaring?  35+ years...

> 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.

Oh, here we go again.  Another long-time,
hardcore, advanced user trying to speak for
the unwashed masses of potential newbies who
are claimed to suffer from some longstanding
behavior.

Yes, the status quo gets more support, by
default.  If the opposite were true we
wouldn't have Emacs as we know it.  Every
fly-by-night or passing fad would have been
immediately adopted.  Churn, churn, churn.

Emacs's design-change conservatism is
recognized too little as one of its strengths.
Change comes with difficulty.  Emacs has a
large, solid user base.  A tiny fraction of
its habits, experience, and preferences get
expressed here.

> having an option to opt-out of this behavior.

What's so special about this behavior that
it should become the new default behavior?

Why not add it as an opt-in, and wait and see
how much support it gains?  What's the hurry?

> (I also think we should add a `describe-command'
> to try to better cover this use-case.)

FWIW, I added `describe-command' to my library
`help-fns+.el' decades ago.  I bind it to
`C-h c' (and I bind `describe-key-briefly' to
`C-h C-c' - I find it less useful than
`describe-command').

https://www.emacswiki.org/emacs/download/help-fns%2b.el