unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active
Date: Sat, 10 Jun 2023 11:28:29 +0300	[thread overview]
Message-ID: <83y1krzpoy.fsf@gnu.org> (raw)
In-Reply-To: <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> (message from martin rudalics on Sat, 10 Jun 2023 08:52:57 +0200)

> Date: Sat, 10 Jun 2023 08:52:57 +0200
> Cc: 63967@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > diff --git a/lisp/window.el b/lisp/window.el
>  > index a11b1a5..6777944 100644
>  > --- a/lisp/window.el
>  > +++ b/lisp/window.el
>  > @@ -8941,7 +8941,9 @@ switch-to-buffer
>  >                       "Cannot switch buffers in a dedicated window")))
>  >                   ('pop nil)
>  >                   (_ (set-window-dedicated-p nil nil) 'force-same-window)))))))
>  > -     (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window)))
>  > +     (save-selected-window
>  > +       (list
>  > +        (read-buffer-to-switch "Switch to buffer: ") nil force-same-window))))
>  >     (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name))
>  >           (set-window-start-and-point (not switch-to-buffer-obey-display-actions)))
>  >       (cond
> 
> That wouldn't help in all other use cases of read_minibuf where the user
> will be thrown back to the minibuffer window as well.  I'd rather try (the
> still timid)
> 
> -static void minibuffer_unwind (void);
> +static void minibuffer_unwind (Lisp_Object);
> ...
> -  record_unwind_protect_void (minibuffer_unwind);
> +  record_unwind_protect (minibuffer_unwind, selected_window);
> ...
> -minibuffer_unwind (void)
> +minibuffer_unwind (Lisp_Object old_selected_window)
> ...
> +	  if (!EQ (old_selected_window, FRAME_SELECTED_WINDOW (f)))
> +	    Fset_frame_selected_window (exp_MB_frame, window, Qnil);
> 
> since the last line seems to suggest that exp_MB_frame should not be the
> selected frame.

That works, but does it make sens to do the other stuff in that if
clause in that case?  We do:

      if (!NILP (w->prev_buffers))
	{
	  entry = Fcar (w->prev_buffers);
	  w->prev_buffers = Fcdr (w->prev_buffers);
	  set_window_buffer (window, Fcar (entry), 0, 0);
	  Fset_window_start (window, Fcar (Fcdr (entry)), Qnil);
	  Fset_window_point (window, Fcar (Fcdr (Fcdr (entry))));
	  /* set-window-configuration may/will have unselected the
	     mini-window as the selected window.  Restore it. */
	  if (!EQ (orig_selected_window, FRAME_SELECTED_WINDOW (f)))
	    Fset_frame_selected_window (exp_MB_frame, window, Qnil);
	}

Does it make sense to manipulate the buffer, window-start, and
window-point of WINDOW if we are not going to make it the selected
window?

In general, I don't think I understand the logic of this function at
all.  Since this is about the "expired minibuffer", then the code
seems to assume that when a minibuffer is "expired", and there are
previous minibuffers for that mini-window, the mini-window stays the
selected-window?  But that is not true when recursive minibuffers are
enabled, right?

IOW, I wonder whether your suggested change just postpones the problem
by moving it to the rarer cases when more than one frame is involved
in this dance.  Why is it okay to set the selected-window of another
frame here?





  reply	other threads:[~2023-06-10  8:28 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
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 [this message]
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=83y1krzpoy.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=63967@debbugs.gnu.org \
    --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).