GNU bug report logs - #26513
25.2; pop-up-frames and *Completions* buffer

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, "Charles A. Roelli" <charles <at> aurox.ch>, 26513 <at> debbugs.gnu.org
Subject: bug#26513: 25.2; pop-up-frames and *Completions* buffer
Date: Thu, 17 Feb 2022 14:21:12 -0500

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.