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: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 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: Sat, 16 Jul 2022 09:06:00 +0200

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

Then how about

  This is driving me crazy. I've tried a zillion ways to try to work around
  this problem, to no avail.

  On MS Windows, whenever a new frame is created, it becomes
  "selected"/"focussed". I use quote-marks here, because I think it might be
  more than what Emacs calls frame selection & focus. I admit that it's
  unclear to me just what's going on.

  ...

  I've tried every hack I can think of, from saving and restoring the selected
  buffer/window/frame, to redirecting and un-redirecting the frame focus, to
  playing with before-make-frame-hook and after-make-frame-functions. I cannot
  get the new frame to become un-"selected"/"focussed" and let me continue to
  use the minibuffer for input.

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

The original commit from 2008 can be studied here:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6355802033d202c63f6fff4b77bf2b0c7aecceef

It was complemented in 2012 by:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c6bf30222430f41fbb696e296f0f63f465eefc35

I have not tried to find out which one is responsible for the current
behavior nor which release first showed it.  The oldest version I can
build here is Emacs 24.  Neither of these commits hints at a prior bug
or discussion explaining why they were considered necessary.

It's interesting that these commits, while mostly acting on the function
unwind_format_mode_line, do not affect the formatting of mode lines via
display_mode_lines because the part of the vector used by these commits
is always NULL, nil or false there.  Hence the later check

  if (WINDOW_LIVE_P (old_window))

always fails when called from display_mode_line and display_mode_lines
correctly restores old window and frame via restore_selected_window.

Restoring the current buffer could be the only worthy contribution of
these changes but ironically is not done from display_mode_line - the
second argument of format_mode_line_unwind_data being NULL there.

>> We should eliminate the original sin and be
>> done with it once and for all.
>
> Probably easier said than done?

It's trivial because display_mode_lines handles it correctly.  The only
difficulty is to convince people that the commits mentioned above are
fundamentally flawed.  So far, my explanations have been met with cold
disregard.

martin

Previous Next

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