bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list

[Drew Adams]

> > Try this:
> > `C-h v org TAB'
> > `M-n'
> > `M-n'
> > ...
> 
> Why candidates are inserted in a random order?
> It would make sense to insert them in the same
> order as they are sorted in the *Completions* buffer.

That's one reasonable possibility.
It's not the only one.

The fact is that the candidates are in
a useless order, particularly when the
completion table is just obarray or an
unsorted, filtered subset of obarray.

Why are all candidates inserted into the 
`M-n' queue at all?  And why no ability
to filter them or sort them - during
completion (i.e., taking the current
completion state into account).

> But then `M-n' will become an equivalent of `M-down'.
> So maybe better to sort candidates by recency/frequency?
> But then how `M-n' will be different from `M-p'?
> 
> I think ideally it should use the same order as used
> by icomplete-mode.

Ideally it should (1) be off by default,
not on, (2) be totally open to program
control, based on current completion state
(e.g. current set of input matches) and
completion history and input history,
(3) filterable, truncatable, etc., and
(4) should have reasonable doc.

A global function-valued variable is maybe
not the best way to add such a feature to
`completing-read' (& compagnie).  Seems
like maybe this feature wasn't well thought
out - the `C-h v' behavior says a lot about
it, I think.

Fundamentally, I think this works _against_
the purpose and idea behind DEF (explicit,
coder-defined list of default values).  It
represents noise pollution, IMHO.

At a bare minimum, the default value of the
function-valued variable should be nil (or
a no-op function), i.e., this new feature
should be OFF by default.