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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 56305 <at> debbugs.gnu.org, acm <at> muc.de
Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Mon, 11 Jul 2022 20:01:52 +0000
Hello, Stefan.

On Mon, Jul 11, 2022 at 13:06:40 -0400, Stefan Monnier wrote:
> > Apologies: the doc string for select-window virtually says it grabs the
> > focus.  Couldn't we go the whole way, and explicitly state that
> > select-window is really "select-window-set-input-focus"?

> This sounds problematic at the very least for cases like
> `with-selected-window` and `save-window-excursion`, where we don't
> really want the code to "set and (un/re)set" the focus.  And similarly
> when code does `select-window` while Emacs doesn't have focus at all.

Actually, at the moment I don't believe that select-window does grab the
focus.  I've been a bit confused about this over the last day or so.

> We do have a kind of messy situation w.r.t distinguishing the notion of
> selected-frame (and selected-window to some extend) from its interaction
> with window-manager focus.  But I'm not sure we can (nor should) really
> unify the two.

No.  But if we did, it would be via an extra argument `no-focus' to
select-window.  I still say no.

>         Stefan

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