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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 56305 <at> debbugs.gnu.org
Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Sun, 17 Jul 2022 10:03:23 -0400

> Fselect_frame (or more precisely do_switch_frame) is a place where the
> trouble occurs, or certainly was before my removal of the 53 lines focus
> redirecting/shifting code ~10 days ago.  That removed code seems to be
> needed for correct frame switching with a minibuffer-only frame, but in
> the middle of do_switch_frame doesn't seem to be the optimal place for
> it.

But the interactive calls have nil for `norecord`.

>> It seems clear to me, for example, that when called with a non-nil
>> `norecord` (like in the mode-line code), `Fselect_window` should never
>> cause any change to the focus redirection (or the focus itself).
>> And neither should it call things like `resize_mini_window`, I think.
>
> It would be a mistake to couple focus switching with NORECORD, something
> which is only coincidentally tied to the focus.

Currently `norecord` is the flag used to indicate that this is an
"internal" `select-window` call, typically part of something like
`with-selected-window` or `save-window-excursion`, which seem like good
candidates to use the more "bare bones" select-window semantics (whose
difference in semantics I don't fully comprehend, to be honest, so
hopefully, this discussion will lead to doc (or at least comment)
changes to describe those differences).

There might indeed be other calls to `select-window` that specify the
`norecord` arg for some other reason, so maybe linking the two that way
is not a good idea, I don't know.

> Neither can I, but Martin's spent quite a few years analysing these
> things.  The mechanisms of these bugs, and their connection with that
> 2008 patch are likely involved and complicated.

Yes, I didn't mean to say they didn't exist, just that I wasn't able to
see them.

> The current state of affairs is that Emacs 28 is unusable to some
> people who prefer a separate minibuffer frame (in particular, Drew
> Adams) and it may well be worth our while to identify the current bugs
> and fix them.

As you might know, I'm in that same boat :-)


        Stefan

Previous Next

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