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

Previous Next

Package: emacs;

Reported by: martin rudalics <rudalics <at> gmx.at>

Date: Wed, 29 Jun 2022 17:55:01 UTC

Severity: normal

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 56305 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca, acm <at> muc.de
Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Fri, 8 Jul 2022 18:31:42 +0000
Hello again, Martin.

On Fri, Jul 08, 2022 at 10:55:07 +0000, Alan Mackenzie wrote:
> On Fri, Jul 08, 2022 at 09:01:43 +0200, martin rudalics wrote:
> >  > I don't follow.  If the WM does "Raise on focus", surely it will
> >  > raise the frame no matter how it acquires the focus.  Such focus is
> >  > here essential for the working of the minibuffer.

> > It should not deliberately raise a frame that already has focus.

> OK.  We could add an extra check for the frame already having the focus.
> Is there anything else suboptimal about that proposed fix to emacs-28?

> >  > Is it not the case that acquiring the focus with Fx_focus_frame
> >  > would be better than not doing so?

> > It does not restore the Emacs 26 behavior.

How, precisely, does the behaviour in my proposed patch differ from that
of Emacs 26?

> > If you look at the reports for Bug#8856, Bug#11566 or Bug#11939, you
> > might be able to imagine how much time I spent to get the behavior
> > right for Drew's setup back then.  It's quite sobering to see my
> > efforts from that period get wasted now.

What do you mean by "wasted"?  What fails to work now which worked
immediately after your fixes for these three bugs?

> .... I'll take a look at these bug reports this evening.

I've had a look at those bugs, now, albeit briefly.  They do not contain
concise recipes for reproducing the bugs, and anyway, I don't have a
Windows system to try things out on.  They are bugs where the focus
ended up on the wrong frame, and it was hypothesised that this may have
been because of Windows always giving the focus to newly created frames.

[ .... ]

> > martin

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 2 years and 330 days ago.

Previous Next


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