bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#26513: 25.2; pop-up-frames and *Completions* buffer
Date: Thu, 17 Feb 2022 14:21:12 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> I have a `display-buffer-alist` entry that does all kinds of funny
>> things for *Completions* ;-)
> Please post it here.

Sorry, top secret.

>> No objection to the patch, but the amount of code duplication in it
>> (both in the new lines and in the surrounding code) suggests we may want
>> to refactor some of that code so that the options processing code is
>> written at a single place "once" rather than
>> once-per-display-buffer-function.
> Agreed.  But I profoundly dislike the sole idea of abusing
> 'redirect-frame-focus' for fixing this kind of problems.

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

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.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]