RE: Key bindings proposal

[Drew Adams]

> > And normal access to the history (as well as access using 
> > completion).
> 
> Any reason why this is still not available in vanilla Emacs?

Why _what_ is not in vanilla Emacs - (a) Icicles or (b) the addition of previous
command inputs to the command history or (c) the ability to complete against
history items?

You know the answer for (a).

(b) _is_ of course available in vanilla Emacs.  Icicles just extends vanilla
minibuffer input, so it maintains this vanilla property.  `Anything' might be a
different story - dunno.

For (c), the answer is that no one has bothered to add the feature to vanilla
Emacs. Note: Completion against the history list has this advantage over cycling
and searching it (`M-p', `M-r'): the age of the input retrieved is irrelevant.


[FWIW - (c) is provided by Icicles in 3 different ways:

c1. During minibuffer input anytime (not necessarily input with completion), you
can use `M-o' to insert a previous input from the input history using completion
(recursive minibuffer).  This is on-demand history completion.  I've suggested
in the past that vanilla Emacs do likewise.

IIRC, at one point you or someone else proposed simply adding previous inputs to
the completion-candidate set.  That is misguided, IMO - the two sets should be
kept separate.  But completion can be allowed independently against both sets -
even during the same input interaction.

c2. During completion, you can use `M-h' to filter the current set of completion
candidates, limiting it to past inputs.

c3. During completion, you can use `M-pause' to filter the (raw/initial) domain
of completion candidates, limiting it to past inputs.

(c2) and (c3) differ in that Icicles lets you progressively filter the set of
candidates or even replace it by a saved set.  (b2) acts on the current set of
candidates; (c3) acts on the domain of candidates defined by the command.]


[FWIW2 - Icicles has additional history-list features, any of which could serve
as food for thought for vanilla Emacs.  Two simple examples: (1) highlight the
previous inputs in *Completions* (optionally: `C-pause' toggles it during
completion); (2) sort the candidates on demand (e.g. putting previous inputs
first).

http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements]

> > I made the point that the solution to the problem Juri described is
> > not to rename the commands but to use better completion
> > (e.g. substring, regexp, pcomplete, fuzzy,...).  That's the point.
> > It does not matter how you get better completion.
> 
> Yes, better completion is what we need.  This includes pushing
> more likely completions to the top of the list.

Be careful, please.  What the program considers "more likely" might not
correspond to what some user considers more likely in a given context.  This
kind of thing should be under user control.

DWIM should always be considered at best only a stupid guess.  It should be
subjected to user control - preferably runtime, on-the-fly control.  Only in
that context can DWIM be useful and not just an annoyance.  Programs can
sometimes help by being smart, but users still know best.

It would be a mistake, IMO, to systematically place previous inputs at the
beginning of the *Completions* list.

Of course, vanilla Emacs does not let you cycle among candidates, so their order
is irrelevant except in terms of what user sees (in *Completions*).  Even so, it
is a bad idea to impose an order such as chronological (previous use).
Alphabetical order has the advantage of making it easy to find a name (think of
an index in a book).

[In Icicles, users can sort completion candidates on the fly in many ways, the
possible sort orders being dependent on the context (and under user control).]

> But it seems in anything-M-x the sorting order of completions is
> randome (at least, I can't deduce any logic behind the order of its 
> completions).