unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: al@petrofsky.org, rudalics@gmx.at, monnier@iro.umontreal.ca,
	63967@debbugs.gnu.org
Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active
Date: Sun, 11 Jun 2023 16:53:48 +0300	[thread overview]
Message-ID: <83zg56xfyr.fsf@gnu.org> (raw)
In-Reply-To: <ZIXO5KNYzNcuEMh-@ACM> (message from Alan Mackenzie on Sun, 11 Jun 2023 13:40:52 +0000)

> Date: Sun, 11 Jun 2023 13:40:52 +0000
> Cc: monnier@iro.umontreal.ca, al@petrofsky.org, rudalics@gmx.at,
>   63967@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Fset_window_configuration seems to be the troublesome function in this
> > > scenario.  As well as setting the window configuration, it also selects
> > > a window.
> 
> > Where is that problem and its circumstances described?  Is there some
> > bug number or a discussion on emacs-devel that you could point to?
> 
> I remember such a discussion vaguely, but after much searching, haven't
> been able to find it again.  Sorry.

Too bad.  If someone can find it, please speak up.  It is important to
know what those situations are to make sure the solution we install
for this bug doesn't break those situations.

> > > Perhaps we should modify the minibuffer code to note which window should
> > > be current after the completion or abortion of the minibuffer read
> > > action.
> 
> > Isn't that simply "the window which was selected before entering the
> > minibuffer"?
> 
> Most of the time, yes.  If that window no longer exists on termination of
> the minibuffer, or we've moved to a different frame, things aren't so
> simple.

So you are saying that minibuffer_unwind exists only for the case when
that window no longer exists?  But if so, where's that condition being
tested, in a way that minibuffer_unwind is a no-op if that window
still exists?

> In read_minibuf (the meat of the minibuffer processing), there is a
> variable calling_window which records that window.  It gets pushed onto
> the binding stack (along with a lot of other variables) around the
> recursive edit, and then possibly restored in the unwind_protect function
> read_minibuf_unwind.  However, restore_window_configuration overrides it,
> because of the order these things are pushed onto the binding stack by
> read_minibuf.

I don't understand the need for recording that window separately.  The
window configuration restored by restore_window_configuration is
supposed to record it.

> Do you want me to fix this bug?  It seems there are quite a lot of people
> who've made observations about it in the last couple of days.

I want to fix the bug whose recipe is in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#5 and other
similar ones, yes.  Basically, if Emacs reads from a recursive
minibuffer when the selected window before that was not a mini-window,
we now signal a user-error, which is a regression since Emacs 28, and
I'd like that to be solved.  But please begin by looking at the
solution proposed by Martin in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#38 and tell if it
looks good to you, and if not, why not.

I'd also appreciate more commentary explaining the rationale for
minibuffer_unwind and the situations where it is needed.  But that is
less urgent.

Thanks.





  reply	other threads:[~2023-06-11 13:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08 21:32 bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Al Petrofsky
2023-06-09 11:16 ` Eli Zaretskii
2023-06-09 15:08   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09 16:09     ` Eli Zaretskii
2023-06-09 19:18       ` Eli Zaretskii
2023-06-10 15:49         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-10 19:42           ` Alan Mackenzie
2023-06-11  5:03             ` Eli Zaretskii
2023-06-11 13:40               ` Alan Mackenzie
2023-06-11 13:53                 ` Eli Zaretskii [this message]
2023-06-13 18:43                   ` Eli Zaretskii
2023-06-13 21:36                     ` Alan Mackenzie
2023-06-14 12:15                       ` Eli Zaretskii
2023-06-15 10:25                         ` Alan Mackenzie
2023-06-17 11:31                         ` Alan Mackenzie
2023-06-17 13:08                           ` Eli Zaretskii
2023-06-17 13:52                           ` martin rudalics
2023-06-17 16:23                             ` Alan Mackenzie
2023-06-17 18:46                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-11 14:35                 ` Drew Adams
2023-06-11 16:01                   ` Alan Mackenzie
2023-06-12  7:17                     ` martin rudalics
2023-06-12 12:04                       ` Eli Zaretskii
2023-06-11 16:12                   ` Eli Zaretskii
2023-06-09 16:52   ` Gregory Heytings
2023-06-09 17:21     ` Eli Zaretskii
2023-06-09 20:04       ` Gregory Heytings
2023-06-10  5:59         ` Eli Zaretskii
2023-06-10  6:39           ` Gregory Heytings
2023-06-10  6:45             ` Eli Zaretskii
2023-06-10  8:45               ` Gregory Heytings
2023-06-10  6:52   ` martin rudalics
2023-06-10  8:28     ` Eli Zaretskii
2023-06-10 14:51       ` martin rudalics
2023-06-10 17:09         ` Eli Zaretskii
2023-06-11  8:10           ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zg56xfyr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=63967@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=al@petrofsky.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).