GNU bug report logs - #24803
Redirection problem with separate minibuffer frame

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24803 in the body.
You can then email your comments to 24803 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: Redirection problem with separate minibuffer frame
Date: Wed, 26 Oct 2016 14:09:00 -0400

Package: Emacs
Version: 26.0.50


I'm seeing redirection problems in my Emacs setup (with separate
minibuffer-only frame).  I suspect it comes from

    commit 421c0512f76683e0b85ea5e1362291c2da4149ba
    Author: Martin Rudalics <rudalics <at> gmx.at>
    Date:   Mon Oct 17 10:52:01 2016 +0200
    
      Fix frame focus redirection with shared minibuffer windows (Bug#24500)
      
      * src/frame.c (do_switch_frame): Redirect frame focus also when
      the frame switched to has its minibuffer window on the selected
      frame.
      * src/window.c (candidate_window_p): To qualify as candidate
      it's not sufficient for the window's frame to just share the
      minibuffer window - it must be active as well.

I just managed to reliably reproduce one of the symptoms of the problem:

    % emacs -Q --eval "(setq default-frame-alist '((minibuffer)))"
    ... place the minibuffer frame so that half of it covers the main frame ...
    ... now from the minibuffer frame, do
    C-h f car RET

at this point, the stacking order has been changed: the main frame is above
the minibuffer-only frame.  Then I move the mouse into the part of the
minibuffer frame still visible and I type

    ffff

The first `f` should call `find-file` (according to
minibuffer-inactive-mode-map), but instead the `ffff` text gets inserted
into the *scratch* buffer because of some inappropriate focus redirection.
[ This recipe depends on using a window-manager with
  focus-follows-mouse and it might also depend on other aspects of the
  window manager's behavior.  ]

A few years back, I had a problem with focus redirection which I tracked
with the patch below.  I never removed the patch after fixing the bug,
so the first symptom of the new problem was that I started to see "Left
over focus redirection!" messages all the time.  At first I thought it
was my patch at fault, so I disabled it, but since then I started to see
various odd behaviors, which I think all get down to the left over
redirection reproduced in the above recipe.

This said, I also noticed something else: ever since this redirection
problem appeared, I often see my cursor furiously blinking very rapidly
for a very short amount of time, every time I select another frame
(which happens all the time with my focus-follows-mouse WM).  I used to
see this also back when I was tracking that old redirection problem, so
I suspect that we have a redisplay bug/inefficiency that's only
triggered when some redirection is in place.


        Stefan


diff --git a/src/minibuf.c b/src/minibuf.c
index 57eea05..dcafc77 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -338,6 +338,18 @@ If the current buffer is not a minibuffer, return its entire contents.  */)
   return make_buffer_string (prompt_end, PT, 1);
 }
 
+static void
+check_no_redirected_focus (void)
+{
+  Lisp_Object tail, frame;
+  FOR_EACH_FRAME (tail, frame)
+    {
+      if (!NILP (FRAME_FOCUS_FRAME (XFRAME (frame)))
+          && !EQ (FRAME_FOCUS_FRAME (XFRAME (frame)), frame))
+	message ("Left over focus redirection!");
+    }
+}
+
 
 /* Read from the minibuffer using keymap MAP and initial contents INITIAL,
    putting point minus BACKUP_N bytes from the end of INITIAL,
@@ -380,6 +392,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   Lisp_Object empty_minibuf;
   Lisp_Object dummy, frame;
 
+
+  if (minibuf_level == 0)
+    record_unwind_protect_void (check_no_redirected_focus);
+
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 

Message #8 received at 24803 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 24803 <at> debbugs.gnu.org
Subject: Re: bug#24803: Redirection problem with separate minibuffer frame
Date: Thu, 27 Oct 2016 19:35:18 +0200

> I'm seeing redirection problems in my Emacs setup (with separate
> minibuffer-only frame).  I suspect it comes from
>
>      commit 421c0512f76683e0b85ea5e1362291c2da4149ba
>      Author: Martin Rudalics <rudalics <at> gmx.at>
>      Date:   Mon Oct 17 10:52:01 2016 +0200
>
>        Fix frame focus redirection with shared minibuffer windows (Bug#24500)
>
>        * src/frame.c (do_switch_frame): Redirect frame focus also when
>        the frame switched to has its minibuffer window on the selected
>        frame.
>        * src/window.c (candidate_window_p): To qualify as candidate
>        it's not sufficient for the window's frame to just share the
>        minibuffer window - it must be active as well.

Please revert the frame.c change so we can be sure which of the two is
the real culprit.

> I just managed to reliably reproduce one of the symptoms of the problem:
>
>      % emacs -Q --eval "(setq default-frame-alist '((minibuffer)))"
>      ... place the minibuffer frame so that half of it covers the main frame ...
>      ... now from the minibuffer frame, do
>      C-h f car RET
>
> at this point, the stacking order has been changed: the main frame is above
> the minibuffer-only frame.  Then I move the mouse into the part of the
> minibuffer frame still visible and I type
>
>      ffff
>
> The first `f` should call `find-file` (according to
> minibuffer-inactive-mode-map), but instead the `ffff` text gets inserted
> into the *scratch* buffer because of some inappropriate focus redirection.
> [ This recipe depends on using a window-manager with
>    focus-follows-mouse and it might also depend on other aspects of the
>    window manager's behavior.  ]

Works as intended on both Windows XP and a GTK+ build with XFCE on
Debian.  I use focus-follows-mouse plus auto-raise-frame though the
minibuffer does _not_ get autoraised when moving the mouse there.
Actually, that's what I would call a misbehavior here ;-)

> +      if (!NILP (FRAME_FOCUS_FRAME (XFRAME (frame)))
> +          && !EQ (FRAME_FOCUS_FRAME (XFRAME (frame)), frame))
[...]
> +  if (minibuf_level == 0)

Hmm... This seems to indicate that I do not remove the redirection when
exiting the minibuffer.  Could you try to augment in read_minibuf_unwind

  if (minibuf_level == 0)
    resize_mini_window (XWINDOW (window), 0);

to something that for each frame redirects focus to itself?  Obviously,
this might fail with recursive minibuffer invocations from two different
frames ...

martin

Message #11 received at 24803 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24803 <at> debbugs.gnu.org
Subject: Re: bug#24803: Redirection problem with separate minibuffer frame
Date: Sat, 29 Oct 2016 18:54:07 -0400

> Please revert the frame.c change so we can be sure which of the two is
> the real culprit.

Reverting the frame.c change seems to fix the problem.

BTW I also just noticed that the bogus (the one I get at the end of my
recipe) focus is "mutual":
- when the mouse points at the minibuffer window, the focus is in the
  *scratch* buffer.
- when the mouse points in the *scratch* window, the focus is in the
  minibuffer!

> Works as intended on both Windows XP and a GTK+ build with XFCE on
> Debian.  I use focus-follows-mouse plus auto-raise-frame though the
> minibuffer does _not_ get autoraised when moving the mouse there.
> Actually, that's what I would call a misbehavior here ;-)

I don't use auto-raise of any kind.  But yes, it's probably dependent on
some aspect of the window manager event sequences.

> Hmm... This seems to indicate that I do not remove the redirection when
> exiting the minibuffer.  Could you try to augment in read_minibuf_unwind
>
>   if (minibuf_level == 0)
>     resize_mini_window (XWINDOW (window), 0);
>
> to something that for each frame redirects focus to itself?

Still haven't found the time to try this, but I just want to mention
that until recently, the focus redirection was usually nil rather than
"redirected to itself".

I'm not sure if there should be a difference between these two states,
but I have the suspicion that not all the C code handles those two
states in the same way (then again, last time I looked at the
redirection code, I concluded that I just don't understand how it's
supposed to work, so maybe it's just my misunderstanding).


        Stefan

Message #14 received at 24803 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 24803 <at> debbugs.gnu.org
Subject: Re: bug#24803: Redirection problem with separate minibuffer frame
Date: Sun, 30 Oct 2016 09:47:17 +0100

> Reverting the frame.c change seems to fix the problem.

As expected.  Please keep it this way for the moment.  If we don't find
a better solution, I'll do the revert on master.  Currently, I'd be more
interested if someone else sees the same or a similar problem.

> BTW I also just noticed that the bogus (the one I get at the end of my
> recipe) focus is "mutual":
> - when the mouse points at the minibuffer window, the focus is in the
>    *scratch* buffer.
> - when the mouse points in the *scratch* window, the focus is in the
>    minibuffer!

With emacs -Q and just ‘display-buffer-alist’ customized and no
minibuffer dialogue in process?  Queer.

>> Hmm... This seems to indicate that I do not remove the redirection when
>> exiting the minibuffer.  Could you try to augment in read_minibuf_unwind
>>
>>    if (minibuf_level == 0)
>>      resize_mini_window (XWINDOW (window), 0);
>>
>> to something that for each frame redirects focus to itself?
>
> Still haven't found the time to try this, but I just want to mention
> that until recently, the focus redirection was usually nil rather than
> "redirected to itself".

Indeed you would have to set it to nil.  And obviously my proposal is
not a solution anyway since someone might want to redirect focus without
any minibuffers being involved in the first place.

> I'm not sure if there should be a difference between these two states,
> but I have the suspicion that not all the C code handles those two
> states in the same way (then again, last time I looked at the
> redirection code, I concluded that I just don't understand how it's
> supposed to work, so maybe it's just my misunderstanding).

I'm currently struggling with focus redirection in various contexts -
for example, when redirecting focus from a parent to a child frame and
back again.  So far it's a lost battle :-(

martin

Message #17 received at 24803 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 24803 <at> debbugs.gnu.org
Subject: Re: bug#24803: Redirection problem with separate minibuffer frame
Date: Wed, 25 Nov 2020 10:26:30 +0100

>  > Reverting the frame.c change seems to fix the problem.
>
> As expected.  Please keep it this way for the moment.  If we don't find
> a better solution, I'll do the revert on master.

I reverted the change now for Emacs 27.2.  Please consider closing this
bug if there are no further complications.

Thanks, martin

Message #20 received at 24803 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 24803 <at> debbugs.gnu.org
Subject: Re: bug#24803: Redirection problem with separate minibuffer frame
Date: Wed, 19 May 2021 10:12:55 +0200

tags 24803 fixed
close 24803 27.2
quit
> I reverted the change now for Emacs 27.2.  Please consider closing this > bug if there are no further complications.
Bug marked as done now.

martin

Previous Next

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