RE: [External] : Re: Current mode command discovery

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

> > Like I said before: instead of removing what seems
> > irrelevant, make them appear after the relevant parts.
> > Otherwise we will lose information when we guess wrong
> > (which is an easy mistake to make, since the assumption
> > that the user always wants only the commands from the
> > current major mode is not always true).
> 
> That defeats the purpose of the feature, which is
> showing what is relevant and ignore the rest.
> Listing the irrelevant commands would only serve
> to confuse and overload the user.

I can speak from experience to say this isn't true.

And I think that completion that prepares candidates
in a particular sort order is quickly picked up by
users - think of fuzzy match sort-score order, for
example.

In Icicles different groups of candidates can be
highlighted differently.  That too can help.

And I think (?) that Emacs added grouped completion
candidates, with group headings in *Completions*
(but I haven't really followed that thread).

What _is_ true is that when more completions are
matched and displayed, that costs processing time.
(But so does filtering them out.)

These things call for both UI and performance
consideration.

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

I know how to use the Emacs help system quite well,
thank you very much.  I also know that being able
to get help on the fly for a given set of things,
and being able to redefine that set on the fly,
are useful - and not just for discovery.

Add to that additional possible actions on
candidates, besides just invocation and help,
and you begin to see why the completion "system"
introduced by Icicles (Helm, Ivy, etc.) are so
useful.

It's about on-the-fly (re-)defining a set of
things, and being able to apply various operations
to any subset of them (including single-candidate
subsets).

This is why I argued to let users filter command
candidates (for `M-x', for example), to limit to
various kinds of commands, including those for
buffers in a given mode.

Give _users_ immediate control, letting them
change which candidates are available on the fly.
We already _do_ that, but the control we give
them, so far, is just over name matching.  There
are umpteen other ways to filter sets of commands
(and other candidates), besides just by name.
___


FWIW, I've even applied this to Isearch, as well.
With `isearch+.el', besides being able to match
buffer text by your text input (search pattern),
you can add and remove filter predicates on the
fly, during Isearch.

https://www.emacswiki.org/emacs/DynamicIsearchFiltering