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

[martin rudalics]

In either case
>>> I have a `display-buffer-alist` entry that does all kinds of funny
>>> things for *Completions* ;-)
>> Please post it here.
>
> Sorry, top secret.

Maybe we really should recommend Drew's package for people setting
'pop-up-frames' to t then.  Or does anyone else put *Completions* into a
separate frame?

> FWIW, my code also uses `redirect-frame-focus` but I agree it's not
> a great solution.

It's counter-intuitive in the OP's scenario since the *Completions*
frame has its own minibuffer window where the dialogue could be
continued as soon as that frame gets selected.  But here the minibuffer
window is not selected.  We provide hundreds sorts of completions and
I've never been able to understand even one of them.

> AFAIK, this all comes down to the fact that when `display-buffer`
> creates a new frame, it will all too often end up being selected by the
> window manager, even though Emacs doesn't want that window to be the
> selected window.
>
> I sadly don't think we have a good answer for that problem.
> I also don't think there's a good reliable way to do that in
> general, currently.  I suspect what we'd need to do is wait for the new
> frame to be "fully" created (not just by us but also on the window
> manager side) and when that is settled we should request to focus back
> to the frame that had focus before the creation.
>
> I'm sadly not well enough versed in that kind of GUI code to know how to
> do it.  And its asynchronous nature makes it worse.

Our present weaponry for dealing with this ('no-focus-on-map' or even
'no-accept-focus') is apparently inadequate or was never even tested.
The only thing I recall is that waiting for the new frame to get
reported (on X it's even never clear which event is responsible for
that) and deselecting it afterwards leads to some sort of flickering.

martin