[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24803: Redirection problem with separate minibuffer frame
From: |
Stefan Monnier |
Subject: |
bug#24803: Redirection problem with separate minibuffer frame |
Date: |
Sat, 29 Oct 2016 18:54:07 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) |
> 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