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

[Drew Adams]

> >> 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').
> 
> I agree that `M-insert' makes sense for inserting the completion from
> the *Completions* buffer to the minibuffer.

It makes sense to use the same key to go both directions (minibuffer <-->
*Completions*), as I mentioned. Why not?

> > 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.
> 
> <M-down> and <M-up> are used by many other programs that open a pop-up
> list of history/completion items.  So they are natural key 
> for most users and especially for newbies.

As I said, there is little connection with the meaning of "next" and "previous".
That's the point.

Slavishly copying other programs is not a sufficient argument, especially when
it comes to key bindings. It can be a secondary argument, but it shouldn't be
the only or the primary argument. Otherwise, Emacs would quickly resemble the
lowest common denominator, or worse. Other programs are for the most part
inferior to Emacs wrt key bindings.

Emacs generally chooses key bindings in a reasoned way. I gave arguments why
down/up should be reserved for successor/predecessor operations, if possible.
You've given no argument for using them for something that is unrelated to that,
beyond saying that some other programs use them to open a popup list.

There is no reason to have two different keys for switching to *Completions*,
which is what you are proposing, AFAICT. If there is already a key that switches
to *Completions*, then why can't users also use it to switch to *Completions*
when it contains the history list? 

Why do they need another key for that? That's like saying that although we
already have `C-f' for forward-char, we should add `C-<whatever>' for
forward-char whenever the buffer contains lines of poetry.

> I also suggest using <M-down> for IDE-like autocompletion that opens
> a pop-up window with completion in a program buffer.  This is usually
> bound to C-SPC in IDE like Eclipse, but C-SPC is already taken for
> set-mark-command in Emacs.
> 
> > 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.
> 
> As there exists already a key that open the *Completions* buffer,
> it makes sense to do the same for the history list.

Makes sense to do what "the same"? Add another key, just for switching to
*Completions* whenever it contains a history list? Why not really "do the same
for the history list" - treat it exactly the same as every other list in
*Completions*? When you say "same" it seems you mean "different".

Unless I'm missing something, all you've done is fill *Completions* with a set
of completions that come from the history list. That's useful, but there is
nothing special about it. Completing previous inputs is no different from
completing command names or file names or buffer names or anything else. Why add
key bindings unnecessarily (Occam)?

You need one minibuffer key binding to let users complete against the history
list; that's all.

> Below is a patch that implements these ideas.
> 
> > 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.
> 
> You earlier objected to using the same keys that have different
> bindings in the minibuffer and outside it (cf. using `TAB' in the
> minibuffer).

Because the indentation binding of TAB is useful in the minibuffer. I made a
specific argument about TAB. You cannot generalize from my opposition to
changing the meaning of TAB in the minibuffer to suppose that I oppose the reuse
of any keys by giving them different minibuffer bindings.

And TAB is a particular case in another sense: it is apparently in demand for
everything under the sun. I argued to reserve it for things that are related to
its existing meanings.

> Since by default M-o is a prefix key for font-lock-fontify
> function, I think we should find another key.

I chose `M-o' precisely because its global binding is not useful in the
minibuffer. (Do you think it is?) This is not about blanket rules; you have to
consider the details - TAB is not `M-o'.

But I don't care whether you use `M-o' or not. It was just a suggestion. I do
care that you not use TAB for that, with or without modifiers.

> One candidate I propose is C-M-TAB.

When will you guys leave TAB alone? Save M-TAB, S-TAB, C-M-TAB, C-S-TAB, and so
on for operations that are more closely related to TAB's existing behaviors (and
there are already enough of those!). Yes, you could make an argument that this
behavior is slightly related, but tomorrow we will find 23 other possible uses
for TAB that are all more closely related.

I also suggested that completion against the current history use a recursive
minibuffer, and that the choice be inserted into the parent minibuffer for
editing. That is useful, especially for minibuffer input that does not involve
completion. You don't want to be limited to completing the current input against
a previous input. You might want to insert more than one previous input (using
completion), and edit the combination.

I don't agree with any of the proposed changes, but I have no illusions that my
disagreement will make any difference. On n'arrete pas le "progres".