unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: martin rudalics <rudalics@gmx.at>
Cc: 48674@debbugs.gnu.org, "Iris García" <iris.garcia.desebastian@gmail.com>
Subject: bug#48674: Frames and minibuffer bug
Date: Fri, 28 May 2021 20:14:41 +0000	[thread overview]
Message-ID: <YLFPMeefq8tB/aqM@ACM> (raw)
In-Reply-To: <YLElObwqkMoJvs/y@ACM>

Hello, Martin.

On Fri, May 28, 2021 at 17:15:37 +0000, Alan Mackenzie wrote:
> On Fri, May 28, 2021 at 10:26:32 +0200, martin rudalics wrote:

[ .... ]

> > But why precisely does Fselect_window fail here?

> Sorry, my last night's reply wasn't very clear.  That Fselect_window in
> do_switch_frame will fail when a later Fselect_window (or more precisely,
> Fset_frame_selected_window) in move_minibuffers_onto_frame selects a
> different window for that frame.  That happens when with-selected-frame
> selects a different frame, moving the minibuffers onto that other frame.

> I have another idea for solving this problem.  Suppose when we switch
> from F1 to F2, and F1's selected window is the mini-window, we allow F1
> to remain in the MW.  The minibuffer stack gets moved to F2.  Some sort
> of commands or Lisp runs in F2, then we return to F1.  Should any
> minibuffer come back to F1, we allow the MW to remain selected.
> Otherwise we select a different window in F1.

> I think this would work better that what I proposed last night.  I'll try
> and formulate a patch for this this evening.

I think the following patch, along the above lines, solves the bug
completely.  Could you review it for me, please?



diff --git a/src/minibuf.c b/src/minibuf.c
index cffb7fe787..c97a672ad6 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -192,10 +192,10 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion)
   struct frame *f = XFRAME (selected_frame);
 
   minibuf_window = f->minibuffer_window;
-  if (!(minibuf_level
-	&& (for_deletion || minibuf_follows_frame () || FRAME_INITIAL_P (of))))
+  if (!(for_deletion || minibuf_follows_frame () || FRAME_INITIAL_P (of)))
     return;
-  if (FRAME_LIVE_P (f)
+  if (minibuf_level
+      && FRAME_LIVE_P (f)
       && !EQ (f->minibuffer_window, of->minibuffer_window)
       && WINDOW_LIVE_P (f->minibuffer_window) /* F not a tootip frame */
       && WINDOW_LIVE_P (of->minibuffer_window))
@@ -203,15 +203,12 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion)
       zip_minibuffer_stacks (f->minibuffer_window, of->minibuffer_window);
       if (for_deletion && XFRAME (MB_frame) != of)
 	MB_frame = selected_frame;
-      if (!for_deletion
-	  && MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
-	{
-	  Lisp_Object old_frame;
-	  XSETFRAME (old_frame, of);
-	  Fset_frame_selected_window (old_frame,
-				      Fframe_first_window (old_frame), Qnil);
-	}
     }
+  /* If the new frame's selected window is the mini-window, select
+     some other window if we don't have an active minibuffer there.  */
+  if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f)))
+      && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents))
+    Fselect_window (Fframe_first_window (selected_frame), Qnil);
 }
 
 DEFUN ("active-minibuffer-window", Factive_minibuffer_window,


-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2021-05-28 20:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 11:23 bug#48674: Frames and minibuffer bug Iris García
2021-05-26 17:45 ` martin rudalics
2021-05-27 10:34   ` Alan Mackenzie
2021-05-27 16:33     ` martin rudalics
2021-05-27 19:56       ` Iris García
2021-05-28  8:25         ` martin rudalics
2021-05-28  9:34           ` Iris García
2021-05-28  9:51             ` martin rudalics
2021-05-31 16:36         ` Alan Mackenzie
2021-06-01 11:29           ` Iris García
2021-05-27 20:01       ` Alan Mackenzie
2021-05-28  8:26         ` martin rudalics
2021-05-28 17:15           ` Alan Mackenzie
2021-05-28 20:14             ` Alan Mackenzie [this message]
2021-05-29  9:20               ` martin rudalics
2021-05-29 13:10                 ` Alan Mackenzie
2021-05-29 15:12                   ` martin rudalics
2021-05-29 15:24                     ` Eli Zaretskii
2021-05-29 17:00                     ` Alan Mackenzie
2021-05-30 13:58                       ` Alan Mackenzie
2021-05-31  7:55                         ` 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=YLFPMeefq8tB/aqM@ACM \
    --to=acm@muc.de \
    --cc=48674@debbugs.gnu.org \
    --cc=iris.garcia.desebastian@gmail.com \
    --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).