GNU bug report logs - #56305
29.0.50; 'yes-or-no-p' deselects minibuffer frame

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Alan Mackenzie <acm <at> muc.de>
Cc: "56305 <at> debbugs.gnu.org" <56305 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>, "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Tue, 12 Jul 2022 14:56:52 +0000

> The text mirrors the savage wilderness of GUIs - eat and be eaten.
> That's not the clean, well-lighted environment of a tty.

;-)   Well put.

> 'display-buffer', for example, should not select the window it uses.
> But if you display the buffer in a new frame and the window manager
> decides to always give focus to a new frame, that window will be
> selected.  It took me years to convince Drew that Emacs can't do
> anything about that.

Odd.  I have no recollection of ever not being
convinced that frame operations are often beyond
Emacs's control (i.e., that window mgrs rule the
roost), or that `display-buffer' isn't, itself,
about selecting a window.

But likely this is an abstract interpretation on
your part of some concrete discussion about some
concrete problem/bug.  The devil of whatever
disagreement is likely in the details - that's
my guess.

> You're barking at the wrong tree.  That code worked well for half of
> its lifetime.  What really got us into the present bredouille was commit
> 6355802033d202c63f6fff4b77bf2b0c7aecceef and its ill-fated decision to
> call Fselect_window instead of directly setting selected frame and
> window as the well-established and tested code in display_mode_lines
> did and still does.

As I don't follow commits, could you situate the
change you're talking about in terms of a given
Emacs release or past discussion (e.g. bug thread)?
I'm curious about what got broken when (and why).

> In the sequel, obscure bugs began to pile up, all very difficult to
> describe and reproduce (Bug#23124, Bug#24285, Bug#34317) and were fixed
> with some trickery.  The origin of all that evil remained in place.
> Making the minibuffer follow the selected frame was just the final
> stab.

Thanks for such history.  I haven't experienced
the fallout from the minibuffer following the
selected frame (I'm stuck in Emacs 26).  But I
appreciate getting your perspective about what's
been going on.

> We should eliminate the original sin and be
> done with it once and for all.

Probably easier said than done?

Previous Next

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