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

[martin rudalics <rudalics@gmx.at>]

 > (The frame is iconified in this case for me.)  I wouldn't mind if the
 > frame just stayed where it was (i.e. no iconification), and I think this
 > can be done quite easily by overriding the function
 > `minibuffer-hide-completions', and possibly by dedicating the
 > *Completions* buffer to the window displaying it in its own frame
 > (otherwise it can happen that the frame ends up showing some other
 > buffer -- not yet sure how this happens).  Other ideas welcome, of
 > course.

I must admit that I never use completion after M-x.  I was simply
stupefied by the fact that it immediately executed a command instead of
putting the command into the minibuffer, let me regard it and execute it
after I typed RET there.

 > But the main issue for now lies in focus being given to the
 > *Completions* frame when completion is initiated.  The equivalent with
 > `pop-up-frames' equal to nil would be if the *Completions* window was
 > selected after hitting TAB during completion.  It's not intuitive.

It should be now possible to do that on X and Windows by using the
'no-focus-on-map' parameter I added this week.  I'm not sure whether
such a thing exists for NS.  By default, a new Window Manager window
always gets focus.  Taking it away from the window right after creation
might be tricky, sometimes.

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?

martin