bug#26513: 25.2; pop-up-frames and *Completions* buffer

[charles@aurox.ch (Charles A. Roelli)]

>> Really?  But selecting a completion with the mouse or with RET in the
>> *Completions* window with pop-up-frames set to nil does the same.
>
> Yes.  But I never noticed.  I could have sworn that I had to type RET
> somewhere to confirm that I really wanted to do what I picked with the
> mouse or via RET in the *Completions* buffer before.

Have you ever tried Drew's icicles library before?  If you load it from
emacs -Q and enable it with M-x icicle-mode, and type M-x global- TAB
as before, then hitting TAB "cycles" to the next completion in the
*Completions* buffer.  Cycling in this case means two things:

a) Replacing the current minibuffer input with the completion cycled to,
   and highlighting it as the active region in the minibuffer
b) Moving point in the *Completions* window to the selected completion
   and highlighting it with a special face there as well.

But the *Completions* window is never (to my knowledge) the selected
window for the user.  This would be a good model to follow (IMO): the
user can initiate completion with TAB, using it to complete, say, an
initial prefix, and then hit TAB a few more times to cycle to a chosen
candidate, all without ever leaving the minibuffer window.

>> Granted, though, it's probably not a very common thing to do.
>>
>> And also, sorry if this was not clear, but this bug is for completion
>> everywhere in Emacs, not just M-x.
>
> That's why I asked.  I now think that for most users the behavior that
> the frame is selected is quite normal (for M-x) and I rather would
> expect the *Completions* window to be selected too when it appears on
> the same frame.  The current behavior is inconsistent.

See above for a way to allow cycling candidates with TAB without the
*Completions* window having to be selected.  In other applications (say,
the bash shell), hitting TAB to complete something never prevents you
from continuing to type (as would happen in Emacs if the *Completions*
window were always selected when you initiate completion).

>> Thank you; I wasn't aware of this.  Now it makes sense why the
>> *Completions* frame gets focus.  One solution to this problem, then,
>> might be to create a separate *Completions* frame on startup and update
>> it with completions as necessary, without ever deleting/recreating it.
>> I'll see if I can write a mode or something for this.
>
> Even then it might get focus.  With a focus follows mouse policy, raising
> a frame that happens to be under the mouse pointer will usually also
> focus it (blame the window manager for that).

True, I will have to try it out and see if that's a problem.

>>> Still, why would you want to "continue typing in the minibuffer" when
>>> the desired effect of what you do is to choose and execute one of the
>>> commands shown in the *Completions* buffer?
>>
>> As explained above, it isn't necessarily the desired effect, only one
>> example.
>
> Maybe it would then make sense to discriminate the use cases of
> *Completions*: One where continuing typing in the selected window
> wouldn't make sense because one has to select an item in the
> *Completions* buffer.  In that case selecting the *Completions* window
> makes perfect sense IMHO.  And one where you usually want to continue
> typing and the *Completions* buffer is just there for later perusal.

Again, see above for Drew's approach, since it allows both use cases
easily.