RE: Leaving out non-applicable commands on Mx

[Drew Adams <drew.adams@oracle.com>]

> On the M-x prompt, the set of candidates is restricted to those that
> make sense given the current context.

Not if a user invokes `M-x' to see which commands are currently
available in general, i.e., as a kind of interactive `apropos'.
(Especially if s?he can hit a key to get help about the command.)

Especially if you have an "advanced completion system" that
lets you (a) match command names more flexibly and (b) narrow
the matches using a succession of patterns.

> Leaving out functions that are
> specific to modes not enabled is a start.

And that's also a feature of some "advanced completion
systems".  But it should not (except by user option) be
the default behavior. The default behavior should be all
candidates matching the input patterns and the completion
predicate - no other "helpful" filtering unless requested
by the user.

The command calling `completing-read' or `read-file-name'
(or whatever) should get first shot at specifying the
filtering.  And it does that, as usual, with a predicate.

> So if you are editing a C file and press `M-x g' almost
> all gnus* functions shall not be considered as
> candidates for completion.

Yes they should, by default - unless a user has configured
a different behavior.

Emacs is smartest when it doesn't try to outsmart the user;
when it helps the user be smart instead of trying to
second-guess her.

It's about what the user wants, not what an Emacs developer
thinks is clever or is what the user must want.

But hey, I sympathize wrt the many matches of something
like `gnus'.  I filter those out by matching & tossing
them - unless I really want to see them for some reason.

Let the specific _command_, first, and the _user_ who
invokes it, second, filter out stuff that is not appropriate.

Please don't decide ahead of time (unless it's through a
specific command) what is appropriate and what is not.

> This is important with advanced completion systems.

See above about "advanced completion systems".

> An example: while working on a org-mode file, if I wish
> to execute org-clock-report I can use its binding:
> "C-c C-x C-r".  With ido+flx, I can do "M-x ocr ENTER"
> which, IMO, is superior on each and every aspect.

And?  Are you now suggesting that users and libraries
should not bind keys because you are convinced that your
"advanced completion system" is "superior on each and
every aspect"?  I hope not.

> The M-x interface can be an improvement over both keybindings and the
> menu on terms of usability, given the correct methods, but having
> thousands of irrelevant candidates every time you invoke M-x is an
> inconvenience for that goal, not to say plain dumb.

Thousands of candidates might be just what a user wants.
But more importantly is to let the _user_ choose which
100 or which 10 of the thousands s?he really wants to
interact with.

Please don't presume to guess, in some general way, how a
user might want to filter candidates.

Specific commands already can, and do, make such judgments
(e.g. only symbols bound to commands are candidates for `M-x).

Leave it up to the command (and to the user who chooses
to use that command) to make such a preliminary judgment.

And more importantly, leave it up to the user to decide
how to subsequently filter the preliminary candidates.

What Emacs could do to help is to:

1. Provide powerful and flexible ways to match, and to
combine multiple match patterns.

2. Provide command-specific keys to use during completion,
to let the user filter in ways that are helpful in the
context of that command.

As one example (and I'm sure there are plenty of others),
Icicles lets you narrow using any number of patterns,
each of which can be a regexp or a fuzzy-match of various
kinds.  You can exclude matches as well as including them.

And for buffer-name candidates, for example, you can use
keys to keep or remove the names of buffers in a derived
mode or a given mode or that are already displayed or not.

(You can even provide a filtering predicate interactively,
on the fly, to narrow candidates any fancy way you like.)

What Icicles offers is not the only way to help users
filter.  The point is to try to do that, not try to
guess, in some general way, what kind of filtering is
good for them for all commands.

The way to do what you suggest wrt commands that make
sense for a given mode ("leaving out functions that are
specific to modes not enabled is a start") is to let the
user hit a key to do this, i.e., to ask for it on demand,
not to impose it on everyone and everywhere by default.