RE: Limit what M-x TAB lists?

[Drew Adams]

> > An alternative approach can be changing the order of items.
> > The more frequently a command is used the higher it would be
> > listed, so your most frequently used commands would float to
> > the top of the completion list and you'd find them easier.
> 
> FWIW, Icicles can do this (it also fontifies commands you've
> used at all differently from those you have not).
> 
> (Icicles is so different from normal completion that I'm not
> even sure I should be mentioning it. But still.)

Why not mention Icicles?  It shouldn't be hard to do things in
vanilla Emacs that are similar to Icicles features.  Where
there's a will there's a way.

(And FWIW, Icicles completion is less different from "normal"
completion than is, say, Ido completion.  Icicles completion
is pretty much a superset of "normal" completion.  Unlike Ido,
it uses the minibuffer and *Completions* "normally".  If you
don't hit extra keys then the behavior you get is pretty
"normal".)

First, a comment on the above suggestion that Nix replied to:
IMO, systematically floating more recent inputs to the start
of a completion list would take control away from the user,
unless it it is easy to turn off that behavior (e.g., while
completing).

What Nix says about Icicles is correct.  But the following
info might not be obvious, and it might help in this context.
Items 1-7 are about sorting; 8-9 are about minibuffer
histories.  All of what is said here applies to all kinds of
completion, not just command completion (`M-x').

1. Users control the sort order, and can change it on the fly
at any time.  Likewise, reversing the current sort order.

2. Some sort orders are available as choices for all types of
completion.  Others are specific to particular completion
types (e.g. file-name completion) or even to particular
commands.  It is easy for a command to make use of a given
set of sort orders.

3. You can choose a different sort order (or no sorting) by
cycling among orders or by matching their names using
completion.  You use `C-,' to do this.

Cycling is quick when there are not many orders to choose
from.  Completion can make sense otherwise, and when there
are some orders you do not want to enable.  (Some orders are
more costly in time - they are called out in the doc.)

A user option defines a threshold, at or below which cycling
of sort orders is used by default and above which completion
is used by default.  The default threshold is 7 sort-order
candidates.  A prefix arg flips the behavior: if `C-,' would
currently cycle then it completes instead, and vice versa.

5. In addition to choosing another sort order, you can toggle
between the current sort order and the current alternative
sort order - a quick way to flip between two orders.

You can choose different alternative sort orders in the same
ways you choose the current sort order: cycling or completion.
By default, the alternative sort order puts previously used
inputs first, sorting those candidates and the others
alphabetically.

6. You can easily define additional sort orders or remove
existing sort orders from the base set.

7. You can even combine existing sort orders interactively,
melding them together in various ways.

8. You can toggle the highlighting that Nix mentioned for
previous inputs, anytime from the minibuffer.

9. There are two ways to limit completion candidates to those
that have been input previously:

    * `M-pause' resticts the currently matching candidates to
      ones that have been entered before.
    * `M-h' matches minibuffer content against previous inputs.

More info:

* http://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates
* http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements