Subject: bug#24803: Redirection problem with separate minibuffer frame

From: martin rudalics <[email-masked]>
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