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

[Drew Adams <drew.adams@oracle.com>]

> 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?

tl;dr: No, please don't.
___

No, I don't recommend that.  I try to keep it working
across Emacs releases, but it's not to be depended on.

In addition, for real reasonable behavior wrt frame
focusing etc. I find using Icicles with it to be
almost a necessity.

I mentioned it only FWIW, to suggest maybe a way to
approach the problem (redirect the frame focus from
a dedicated *Completions* frame to a standalone
minibuffer frame).

The problem is a general one, and twofold, IMO:

1. Window managers, not Emacs itself, have ultimate
control over the behavior of frames.

2. Most Emacs users, including most Emacs developers,
use Emacs windows for most buffers.  They don't try
to use separate frames in general.  As a result (IMO),
the behavior of frames in Emacs gets much less love
than the behavior of windows (placement etc.).

This situation is a given, I'm afraid.  And it's
understandable.

Back in the early 90s there was an Emacs called
Epoch.  It had (by default, IIRC) a standalone
minibuffer frame, and for most things (IIRC) it
used what GNU Emacs calls frames.  And it just
worked.  Since that's the way it was defined -
the default, that's what got maintained, developed,
etc.

When I changed to use GNU Emacs again I tried to
reproduce a setup like that of Epoch.  I found
many hurdles and hoops, and I only partially have
been able to jump over and through most of them.

Long ago I wrote some on this, here (including
the linked pages):

https://www.emacswiki.org/emacs/OneOnOneEmacs

>  > 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.

I sympathize.  Yeah, it's a jungle out there.

> 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.

(I'm not familiar with `no-accept-focus' and
`no-focus-on-map'.  I see them now, in
(elisp) `Management Parameters'.)

Wrt frame focus problems stemming from some
window mgrs focusing a new frame etc.: I wonder
whether it might help (in the case of dedicated
frames) to pre-create the relevant frames such
as *Completions*, and instead of deleting them
and re-creating them, make them invisible and
show them again.

Dunno.  I don't recall whether I ever tried
such an approach.  And maybe we'd run into
problems from different window mgrs handling
visibility of frames in different (odd) ways.
(See problem #1, above.)