RE: C-r and C-s in minibuffer should search completion

[Drew Adams]

> Normally <prior> is bound to previous-history-element, but in some
> minibuffers it is bound to switch-to-completions.

Yes, that is poor design, IMO. Not the fact that it has a different meaning in
different minibuffer maps (completion vs no completion), but the fact that the
`prior' key is naturally associated with the `next' key, and Emacs does not
exploit that association - it breaks it.

> Maybe we should avoid this inconsistency by using
> another key for switch-to-completions?

FWIW, Icicles uses `C-insert' for this. And hitting it again takes you back to
the minibuffer (and copies the completion at point in *Completions* to the
minibuffer` for editing). That key won't work for emacs -nw, but `M-insert'
presumably would (in the form of `ESC insert'). 

(Icicles uses `insert' itself for something else. And Emacs likewise should
perhaps reserve `insert' for something that needs to be quick. Switching buffers
need not be so quick as to deserve a single key.)

> What about binding switch-to-completions to <M-down> because typing
> simply <down> starts moving to the next item in a list of defaults
> and completions. And also to bind a new command switch-to-history
> (that will display a list of history items in a separate window)
> to <M-up> because simply <up> moves to the previous history item.

Your association is a bit far-fetched, IMO - you are stretching things to fit
your proposal, rather than proposing something that seems natural.

There is little connection between the idea of having `down' and `up' move to
the next and previous items in a series and the idea of switching
windows/buffers.

Other things being equal: Keys that form natural pairs, such as `down'/`up',
`next'/`prior', and `home'/`end' should be reserved for things that perform some
sort of succession (i.e., next or previous) behavior. Or for some sort of
bracketing (e.g. grouping) behavior, such as start-something...end-something. Or
for some sort of complementary behavior (e.g. `insert'/`delete'). The same is
true for other such natural pairs of keys: (), [], {}, <>.

Succession is a natural choice for pairs, such as `next'/`prior', whose names
suggest succession. Opposite behavior can be a natural choice for pairs, such as
`insert'/`delete', whose names suggest that.

Finally, why use a separate window for history items? Why not simply use
*Completions* and let users complete against history items? IOW, use the normal
completion mechanism, with everything that it provides.

That is what I suggested when I mentioned `M-o', which is the key that Icicles
uses for this. You can use `M-o' from any minibuffer, not just during
completion. It uses a recursive minibuffer to let you choose from the current
input history (using completion) - your choice is inserted in the minibuffer,
where you can edit it for the original minibuffer reading.