bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

Not a recipe from emacs -Q - sorry.  Please bear with my description.  I
don't claim to understand things 100%, but this is what I think is going
on.  I really hope that someone who understands better can help.
 
Normally, if you have a standalone minibuffer frame, then when
`read-from-minibuffer' is called the input focus switches to that frame
- which it should, so that your typed input goes into the minibuffer.
 
However, it can happen that the focus sometimes does not go to the
minibuffer frame (or perhaps it leaves that frame? dunno).  And that's
the problem I'm looking for a solution to.
 
On MS Windows at least, when a new frame is created it grabs the input
focus.  The problem where the minibuffer frame does not get the focus it
needs seems to arise in a situation where a new frame is popped up and
then `read-from-minibuffer' is called immediately afterward.  Maybe
there is some kind of contention or delay/race problem here (?) - I have
no idea.
 
For example, `dired-mark-read-string' calls `dired-mark-pop-up' to read
a string using `read-from-minibuffer' (`r-f-m' is the FUNCTION arg
passed to `d-m-p-u' in this case).
 
Inside a `save-window-excursion', `dired-mark-pop-up' then calls
`dired-pop-to-buffer', which pops up a new buffer, which (let's say,
because of `special-display-regexp' or whatever) is shown in a new
frame.  MS Windows gives this frame the input focus.
 
Then, still inside the `save-window-excursion', `dired-mark-pop-up'
immediately calls the FUNCTION arg, which in this case is
`read-from-minibuffer'.  (It does this using (apply FUNCTION args), but
that should not make any difference.)
 
[I don't think it matters for correctness whether the (apply FUNCTION
args) is inside the `save-window-excursion'.  I've tried moving it
outside, but that did not change anything.  I would think that it should
be outside logically (why perform the action from that buffer?), but I'm
not knowledgeable about all use cases of `dired-mark-pop-up'.]
 
OK, so what happens is this: When `read-from-minibuffer' does its thing,
the standalone minibuffer does not receive the user input.  Instead, the
input goes to the popped-up frame (which has a list of *Marked Files*).
 
That seems to be an exception to the general rule that
`read-from-minibuffer' correctly moves the focus to the minibuffer - and
to its frame.  I don't know why there is a difference in this case, but
that seems to be what happens.  The problem is not specific to this
example - it can occur at other times.  But I think that this is a good
case to follow what's happening.
 
I've tried various workarounds, with more or less success.  But I'm
thinking now that the problem is not in any such functions that pop up a
frame etc. but rather with `read-from-minibuffer' itself.  Shouldn't it
have the responsibility here to give the minibuffer frame the focus?
 
Here is a workaround I've come up with when trying to "fix" `r-f-m'
itself:
 
(defadvice read-from-minibuffer (around focus-standalone-minibuf activate)
  "..."
  (let ((selframe  (selected-frame))
        result)
    (unwind-protect
         (progn (when (and (boundp '1on1-minibuffer-frame)
                           (frame-live-p 1on1-minibuffer-frame))
                  (select-frame-set-input-focus 1on1-minibuffer-frame))
                (setq result  ad-do-it))
      (ignore-errors (select-frame-set-input-focus selframe))
      result)))
 
(In my case I know that the standalone minibuffer, if it exists, is the
value of `1on1-minibuffer-frame'.  Not sure how the use of a standalone
minibuffer would be detected in general - presumably by checking for a
frame that has a `minibuffer' parameter with value `only'...)
 
But that defadvice does not always make `r-f-m' DTRT, in any case.  For
example, if the originally selected frame is deleted during `ad-do-it',
then it punts and leaves the input focus in the minibuffer frame.  What
I would probably expect (want) in that case is for the previously
selected frame to get the focus.
 
For example, if I tweak `dired-mark-pop-up' so that it deletes the
popped up frame at the end, then - since that frame was selected (by the
window manager) when `read-from-minibuffer' was called - the minibuffer
frame ends up with the focus.
 
(And I do tweak `d-m-p-u' that way, because of another problem with such
a popped up frame - see bug #7533.)
 
Any help is appreciated.  Hope I've made the problem clear enough,
though you would probably have to be on Windows to see it manifested.
I really hope that someone with better understanding than I can help.
(Stefan? Martin? ...)

In GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600)
 of 2012-05-16 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[martin rudalics]

 > On MS Windows at least, when a new frame is created it grabs the input
 > focus.  The problem where the minibuffer frame does not get the focus it
 > needs seems to arise in a situation where a new frame is popped up and
 > then `read-from-minibuffer' is called immediately afterward.  Maybe
 > there is some kind of contention or delay/race problem here (?) - I have
 > no idea.

You should be able to check this by inserting a (sit-for 1) somewhere in
between popping up the frame and calling `read-from-minibuffer'.

 > For example, `dired-mark-read-string' calls `dired-mark-pop-up' to read
 > a string using `read-from-minibuffer' (`r-f-m' is the FUNCTION arg
 > passed to `d-m-p-u' in this case).
 >
 > Inside a `save-window-excursion', `dired-mark-pop-up' then calls
 > `dired-pop-to-buffer', which pops up a new buffer, which (let's say,
 > because of `special-display-regexp' or whatever) is shown in a new
 > frame.  MS Windows gives this frame the input focus.
 >
 > Then, still inside the `save-window-excursion', `dired-mark-pop-up'
 > immediately calls the FUNCTION arg, which in this case is
 > `read-from-minibuffer'.  (It does this using (apply FUNCTION args), but
 > that should not make any difference.)
 >
 > [I don't think it matters for correctness whether the (apply FUNCTION
 > args) is inside the `save-window-excursion'.  I've tried moving it
 > outside, but that did not change anything.  I would think that it should
 > be outside logically (why perform the action from that buffer?), but I'm
 > not knowledgeable about all use cases of `dired-mark-pop-up'.]

IIRC _you_ don't need the `save-window-excursion'.  So replace it with a
`progn' and I'm sure you won't notice any difference.

 > OK, so what happens is this: When `read-from-minibuffer' does its thing,
 > the standalone minibuffer does not receive the user input.  Instead, the
 > input goes to the popped-up frame (which has a list of *Marked Files*).
 >
 > That seems to be an exception to the general rule that
 > `read-from-minibuffer' correctly moves the focus to the minibuffer - and
 > to its frame.

IIUC `read-from-minibuffer' uses `redirect-frame-focus' to send the
keystrokes to the minibuffer window.  If that function works for you in
general, we likely have a race condition in this special case.

 > I don't know why there is a difference in this case, but
 > that seems to be what happens.  The problem is not specific to this
 > example - it can occur at other times.  But I think that this is a good
 > case to follow what's happening.
 >
 > I've tried various workarounds, with more or less success.  But I'm
 > thinking now that the problem is not in any such functions that pop up a
 > frame etc. but rather with `read-from-minibuffer' itself.  Shouldn't it
 > have the responsibility here to give the minibuffer frame the focus?

Yes.  But the window manager must not intercept it.

 > Here is a workaround I've come up with when trying to "fix" `r-f-m'
 > itself:
 >
 > (defadvice read-from-minibuffer (around focus-standalone-minibuf activate)
 >   "..."
 >   (let ((selframe  (selected-frame))
 >         result)
 >     (unwind-protect
 >          (progn (when (and (boundp '1on1-minibuffer-frame)
 >                            (frame-live-p 1on1-minibuffer-frame))
 >                   (select-frame-set-input-focus 1on1-minibuffer-frame))
 >                 (setq result  ad-do-it))
 >       (ignore-errors (select-frame-set-input-focus selframe))
 >       result)))
 >
 > (In my case I know that the standalone minibuffer, if it exists, is the
 > value of `1on1-minibuffer-frame'.  Not sure how the use of a standalone
 > minibuffer would be detected in general - presumably by checking for a
 > frame that has a `minibuffer' parameter with value `only'...)
 >
 > But that defadvice does not always make `r-f-m' DTRT, in any case.  For
 > example, if the originally selected frame is deleted during `ad-do-it',
 > then it punts and leaves the input focus in the minibuffer frame.  What
 > I would probably expect (want) in that case is for the previously
 > selected frame to get the focus.

I'm afraid that in this special case the current code will fail as well.

 > For example, if I tweak `dired-mark-pop-up' so that it deletes the
 > popped up frame at the end, then - since that frame was selected (by the
 > window manager) when `read-from-minibuffer' was called - the minibuffer
 > frame ends up with the focus.
 >
 > (And I do tweak `d-m-p-u' that way, because of another problem with such
 > a popped up frame - see bug #7533.)
 >
 > Any help is appreciated.  Hope I've made the problem clear enough,
 > though you would probably have to be on Windows to see it manifested.
 > I really hope that someone with better understanding than I can help.

Try the sit-for approach.  Try to make a standalone example like

(let ((old-frame ... some existing frame))
   (make-frame)
   (redirect-frame-focus old-frame))

and see whether it fails giving focus to `old-frame'.

martin

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

>  > On MS Windows at least, when a new frame is created it 
>  > grabs the input focus.  The problem where the minibuffer
>  > frame does not get the focus it needs seems to arise in a
>  > situation where a new frame is popped up and then
>  > `read-from-minibuffer' is called immediately afterward.
>  > Maybe there is some kind of contention or delay/race problem 
>  > here (?) - I have no idea.
> 
> You should be able to check this by inserting a (sit-for 1) 
> somewhere in between popping up the frame and calling
> `read-from-minibuffer'.

Not too sure what you mean, but the test you proposed at the end of your post
seems to replace this - and it was telling.

> IIUC `read-from-minibuffer' uses `redirect-frame-focus' to send the
> keystrokes to the minibuffer window.  If that function works 
> for you in general, we likely have a race condition in this special case.

If so, what could a solution/fix be for it?

>  > Shouldn't [`read-from-minibuffer'] have the responsibility
>  > here to give the minibuffer frame the focus?
> 
> Yes.  But the window manager must not intercept it.

But that's what seems to be happening (intercept or interrupt or some such).

>  > Here is a workaround I've come up with when trying to
>  > "fix" `r-f-m' itself:...
>  >
>  > But that defadvice does not always make `r-f-m' DTRT, in 
>  > any case.  For example, if the originally selected frame
>  > is deleted during `ad-do-it', then it punts and leaves the
>  > input focus in the minibuffer frame.
> 
> I'm afraid that in this special case the current code will 
> fail as well.

So - at least wrt that particular failing - it shouldn't hurt to add code
similar in effect to my defadvice to the C code for `read-from-minibuffer'?
It's just a question, as I'm not confident that the cure would be benign in all
cases.

In any case, it is not a real fix for the problem.  I hope you might have some
ideas for that.

> Try the sit-for approach.  Try to make a standalone example like
> (let ((old-frame ... some existing frame))
>    (make-frame)
>    (redirect-frame-focus old-frame))
> and see whether it fails giving focus to `old-frame'.

Still not sure what you mean by using `sit-for' (how/where?).  But I tried that
simple example, and yes, it systematically fails to give focus to `old-frame'.
The newly created frame keeps the focus - every time.

That it does this systematically makes me think it is not a race condition but
some other problem.  Placing a (sit-for 20) between the `make-frame' and the
`redirect...' made no difference.  Likewise, with `sleep-for'.  The new frame is
created, but no text is visibly displayed in it for the `sleep-for' period, then
the text appears (and the focus is still in the new frame).  The new frame is
selected as soon as it is created (as told by its title bar being highlighted),
and it apparently remains so throughout.

So it would appear that that is the bug/problem.  How to fix it so that
`redirect-frame-focus' can actually redirect the focus in this case?

I also tried some other things, like calling `force-mode-line-update' at the
end, thinking it might be an Emacs display problem.  And I tried calling
`redirect...' more than once.  But no luck.  I even tried explicitly redirecting
to the new frame and then back to the old frame (and vice versa):

(let ((old-frame  (selected-frame))
      (new-frame  (make-frame)))
  ;; (sleep-for 20)
  (redirect-frame-focus new-frame)
  (redirect-frame-focus old-frame))

So far, no luck getting Windows's attention and actually changing the frame
focus.

Hope you can see some light at the end of the tunnel.  It would really be good
(for me at least) to get this fixed.  I have a hunch that this might be at the
origin of other frame-related problems that I have dealt with more or less
successfully using various workarounds (e.g. calls to
`select-frame-set-input-focus').

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> Here is a workaround I've come up with when trying to "fix" `r-f-m'
> itself:
>  
> (defadvice read-from-minibuffer (around 
> focus-standalone-minibuf activate)
>   "..."
>   (let ((selframe  (selected-frame))
>         result)
>     (unwind-protect
>          (progn (when (and (boundp '1on1-minibuffer-frame)
>                            (frame-live-p 1on1-minibuffer-frame))
>                   (select-frame-set-input-focus 
>                    1on1-minibuffer-frame))
>                 (setq result  ad-do-it))
>       (ignore-errors (select-frame-set-input-focus selframe))
>       result)))

FYI - Not sure why (haven't looked), but that defadvice makes it impossible to
see any messages in the minibuffer.  I need to open *Messages* to see any
messages.  So such an approach is definitely not sufficient.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[martin rudalics]

 >> IIUC `read-from-minibuffer' uses `redirect-frame-focus' to send the
 >> keystrokes to the minibuffer window.  If that function works
 >> for you in general, we likely have a race condition in this special case.
 >
 > If so, what could a solution/fix be for it?

You didn't tell us whether it works for you "in general".  If you work
with two frames for "some time" does `redirect-frame-focus' what it is
supposed to do?  If it doesn't we have a strange situation where, citing
from Ito's comment in bug#11513,

 > > When I run lower-frame function in Emacs frame interactively, Emacs
 > > frame is brought behind of other application window(s) but has focus.
 > > Key inputs are passed to lowered frame.  I tested 4 Windows PC, and
 > > all PCs show the same behavior.

so Windows OT1H handles key input passed to a frame that is not in the
foreground and OTOH doesn't pass key input to another frame even if
explicitly asked to do so.

 >>  > Shouldn't [`read-from-minibuffer'] have the responsibility
 >>  > here to give the minibuffer frame the focus?
 >>
 >> Yes.  But the window manager must not intercept it.
 >
 > But that's what seems to be happening (intercept or interrupt or some such).

That's what we have to find out.

 >> Try the sit-for approach.  Try to make a standalone example like
 >> (let ((old-frame ... some existing frame))
 >>    (make-frame)
 >>    (redirect-frame-focus old-frame))
 >> and see whether it fails giving focus to `old-frame'.
 >
 > Still not sure what you mean by using `sit-for' (how/where?).  But I tried that
 > simple example, and yes, it systematically fails to give focus to `old-frame'.
 > The newly created frame keeps the focus - every time.

I suppose my example was just silly.  Maybe you should try again with

(let ((old-frame (selected-frame))
       (new-frame (make-frame)))
   (redirect-frame-focus new-frame old-frame))

I don't know anything about `redirect-frame-focus' and can't test it
reliably here because I'm using special autoraise-frame settings which
likely interfere with any such focus redirection.

martin

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> You didn't tell us whether it works for you "in general".  If you work
> with two frames for "some time" does `redirect-frame-focus' what it is
> supposed to do?  If it doesn't we have a strange situation 
> where, citing from Ito's comment in bug#11513,

Sorry, I don't know what you mean.  I have been using multiple frames for a long
time, yes.  But I do not directly call `redirect-frame-focus'.  I do call
`select-frame-set-input-focus' in various places.

Does that mean that `r-f-f' works for me in general?  I really have no idea.

>  > > When I run lower-frame function in Emacs frame 
>  > > interactively, Emacs frame is brought behind of
>  > > other application window(s) but has focus.
>  > > Key inputs are passed to lowered frame.  I tested 4 
>  > > Windows PC, and all PCs show the same behavior.

Yes, I was the first to confirm what was reported in bug #11513.

> so Windows OT1H handles key input passed to a frame that is not in the
> foreground and OTOH doesn't pass key input to another frame even if
> explicitly asked to do so.

Apparently so.

(That a window manager can accept input passed to a frame that is not on top in
the stacking order is not exceptional.  That is (was, at least) true for many w.
mgrs on UNIX, where you could even change the input focus without changing the
stacking order ("foreground") just by moving the mouse over a lower frame.)

>  >> Try the sit-for approach.  Try to make a standalone example like
>  >> (let ((old-frame ... some existing frame))
>  >>    (make-frame)
>  >>    (redirect-frame-focus old-frame))
>  >> and see whether it fails giving focus to `old-frame'.
>  >
>  > Still not sure what you mean by using `sit-for' 
>  > (how/where?).  But I tried that simple example, and yes,
>  > it systematically fails to give focus to `old-frame'.
>  > The newly created frame keeps the focus - every time.
> 
> I suppose my example was just silly.  Maybe you should try again with
> 
> (let ((old-frame (selected-frame))
>        (new-frame (make-frame)))
>    (redirect-frame-focus new-frame old-frame))

That puts (keeps) the input focus in old-frame.  So it seems to work as it
should.

(But new-frame has its title and border highlighted as if it had the focus.
Somehow there is a disconnect between the two.  But maybe such highlighting is
intended only to indicate the topmost frame?  Dunno.)

> I don't know anything about `redirect-frame-focus' and can't test it
> reliably here because I'm using special autoraise-frame settings which
> likely interfere with any such focus redirection.

I know less that you, but I can perhaps test it if you suggest what to test.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> Date: Tue, 29 May 2012 11:43:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 11566@debbugs.gnu.org
> 
>  > > When I run lower-frame function in Emacs frame interactively, Emacs
>  > > frame is brought behind of other application window(s) but has focus.
>  > > Key inputs are passed to lowered frame.  I tested 4 Windows PC, and
>  > > all PCs show the same behavior.
> 
> so Windows OT1H handles key input passed to a frame that is not in the
> foreground

Careful with your terminology: at least on MS-Windows, a "foreground"
frame is the frame that has focus and receives input.  So what you say
cannot happen by definition.

In the scenario you cited above, the frame is lowered (i.e. brought
behind, or "below" in Z-order, the other frames/windows), but it is
still the foreground frame and therefore it still has focus and
receives keyboard input.  So it's unclear to me what exactly is the
problem in the OT1H scenario.

> and OTOH doesn't pass key input to another frame even if
> explicitly asked to do so.

I have just fixed a similar problem in bug #11513.  I suggest that
Drew wait until the corresponding binaries are available, and see
whether this problem is solved as well.

The problem in bug #11513 was that a frame that was already a
foreground frame was not raised.  Maybe something similar happens
here.

>  >>  > Shouldn't [`read-from-minibuffer'] have the responsibility
>  >>  > here to give the minibuffer frame the focus?
>  >>
>  >> Yes.  But the window manager must not intercept it.
>  >
>  > But that's what seems to be happening (intercept or interrupt or some such).
> 
> That's what we have to find out.

I don't think this is what happens here.  To raise a frame, Emacs
sends a message with a private code to itself, so I doubt that the
window manager could intercept or interrupt it, even if it wanted to.

> I don't know anything about `redirect-frame-focus' and can't test it
> reliably here because I'm using special autoraise-frame settings which
> likely interfere with any such focus redirection.

According to my reading, it just highlights the frame that had focus
redirected to it.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 29 May 2012 07:12:26 -0700
> Cc: 11566@debbugs.gnu.org
> 
> (That a window manager can accept input passed to a frame that is not on top in
> the stacking order is not exceptional.  That is (was, at least) true for many w.
> mgrs on UNIX, where you could even change the input focus without changing the
> stacking order ("foreground") just by moving the mouse over a lower frame.)

"Stacking order" and "foreground" are 2 different things.  As I wrote
earlier, a "foreground" window/frame is the window that has focus and
gets the keyboard input.  It doesn't have to be on the top of the
Z-order.

> > (let ((old-frame (selected-frame))
> >        (new-frame (make-frame)))
> >    (redirect-frame-focus new-frame old-frame))
> 
> That puts (keeps) the input focus in old-frame.  So it seems to work as it
> should.

No, it keeps focus in new-frame, but makes it so the input you type at
new-frame gets sent to old-frame.  Thus, this:

> (But new-frame has its title and border highlighted as if it had the focus.
> Somehow there is a disconnect between the two.

is normal and expected behavior (AFAIU).

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> Careful with your terminology: at least on MS-Windows, a "foreground"
> frame is the frame that has focus and receives input.  So what you say
> cannot happen by definition.

Got it.  I too was using "foreground" to mean the topmost (highest in the
stacking order), and not the frame that receives keyboard input.

> I have just fixed a similar problem in bug #11513.  I suggest that
> Drew wait until the corresponding binaries are available, and see
> whether this problem is solved as well.

Got it.

> The problem in bug #11513 was that a frame that was already a
> foreground frame was not raised.  Maybe something similar happens
> here.

Dunno.  I don't have a lot of hope that it's related.  But who knows?

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> "Stacking order" and "foreground" are 2 different things.  As I wrote
> earlier, a "foreground" window/frame is the window that has focus and
> gets the keyboard input.  It doesn't have to be on the top of the
> Z-order.

Got it.

> > > (let ((old-frame (selected-frame))
> > >        (new-frame (make-frame)))
> > >    (redirect-frame-focus new-frame old-frame))
> > 
> > That puts (keeps) the input focus in old-frame.  So it 
> > seems to work as it should.
> 
> No, it keeps focus in new-frame, but makes it so the input you type at
> new-frame gets sent to old-frame.

Hm.  Maybe I'm unclear about "focus".  To me, "focus" was about input focus: the
focused frame is the one that accepts/receives keyboard input.

In something like `select-frame-set-input-focus', my interpretation was that
frame selection was related to the border highlighting and setting input focus
was related to receiving keyboard input.  AFAIK, `select-frame' does the former,
but `select-frame-set-input-focus' is needed to get the latter.

> Thus, this:
> 
> > (But new-frame has its title and border highlighted as if 
> > it had the focus.  Somehow there is a disconnect between the two.
> 
> is normal and expected behavior (AFAIU).

Expected from `redirect-frame-focus', I guess you mean.  So IIUC,
`select-frame-set-input-focus' does `select-frame' plus `redirect-frame-focus'?

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11566@debbugs.gnu.org>
> Date: Tue, 29 May 2012 09:10:15 -0700
> 
> > > > (let ((old-frame (selected-frame))
> > > >        (new-frame (make-frame)))
> > > >    (redirect-frame-focus new-frame old-frame))
> > > 
> > > That puts (keeps) the input focus in old-frame.  So it 
> > > seems to work as it should.
> > 
> > No, it keeps focus in new-frame, but makes it so the input you type at
> > new-frame gets sent to old-frame.
> 
> Hm.  Maybe I'm unclear about "focus".  To me, "focus" was about input focus: the
> focused frame is the one that accepts/receives keyboard input.

Well, yes, but redirect-frame-focus explicitly parts them, AFAIU.

> In something like `select-frame-set-input-focus', my interpretation was that
> frame selection was related to the border highlighting and setting input focus
> was related to receiving keyboard input.  AFAIK, `select-frame' does the former,
> but `select-frame-set-input-focus' is needed to get the latter.

On Windows, at least with the default setup, selecting a frame also
grabs focus.  So these two functions do the same.

> > Thus, this:
> > 
> > > (But new-frame has its title and border highlighted as if 
> > > it had the focus.  Somehow there is a disconnect between the two.
> > 
> > is normal and expected behavior (AFAIU).
> 
> Expected from `redirect-frame-focus', I guess you mean.

Yes, of course.

> So IIUC, `select-frame-set-input-focus' does `select-frame' plus
> `redirect-frame-focus'?

No, it just raises the frame after selecting it and makes sure it has
focus (which in most situations it will have by virtue of being
raised).

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11566@debbugs.gnu.org>
> Date: Tue, 29 May 2012 09:10:12 -0700
> 
> > Careful with your terminology: at least on MS-Windows, a "foreground"
> > frame is the frame that has focus and receives input.  So what you say
> > cannot happen by definition.
> 
> Got it.  I too was using "foreground" to mean the topmost (highest in the
> stacking order), and not the frame that receives keyboard input.

Well, it's tricky terminology to be sure.

> > The problem in bug #11513 was that a frame that was already a
> > foreground frame was not raised.  Maybe something similar happens
> > here.
> 
> Dunno.  I don't have a lot of hope that it's related.  But who knows?

One can hope.

However, in the interests of clarity, could you please describe the
bug again, in terms of which frame has focus (i.e. is the "foreground"
window), which is at the top of Z-order, and which has its border
highlighted, after read-from-minibuffer is called, as you described in
your original report?

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> However, in the interests of clarity, could you please describe the
> bug again, in terms of which frame has focus (i.e. is the "foreground"
> window), which is at the top of Z-order, and which has its border
> highlighted, after read-from-minibuffer is called, as you described in
> your original report?

When `dired-mark-pop-up' calls `dired-pop-to-buffer' (inside a
`save-window-excursion', a new frame is created (to show the *Marked Files*).  

The new frame gets the input focus, and its border is highlighted.  Can't tell
about the stacking order, since my standalone minibuffer frame does not overlap
it.

Then when `dired-mark-pop-up' calls `read-from-minibuffer' immediately
thereafter, the input focus remains where it was, and likewise the border
highlighting.

`read-from-minibuffer' usually gives the minibuffer frame the input focus (and
border highlighting - but I really don't care about that).  But in this case,
i.e., immediately following the new-frame creation, it does not.

HTH.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> > In something like `select-frame-set-input-focus', my 
> > interpretation was that frame selection was related to the
> > border highlighting and setting input focus
> > was related to receiving keyboard input.  AFAIK, 
> > `select-frame' does the former, but `select-frame-set-input-focus'
> > is needed to get the latter.
> 
> On Windows, at least with the default setup, selecting a frame also
> grabs focus.  So these two functions do the same.

No, definitely not with my (non-default) setup.  Selecting a frame does not give
it the input focus.

Hence my need to call `select-frame-set-input-focus' in a few places.  And, I
would guess, hence the existence of two different functions: `select-frame' and
`s-f-s-i-f'.

I'm no expert on any of this, obviously.  I added `s-f-s-i-f' long ago where I
found I needed it - `select-frame' was not sufficient.

> > So IIUC, `select-frame-set-input-focus' does `select-frame' plus
> > `redirect-frame-focus'?
> 
> No, it just raises the frame after selecting it and makes sure it has
> focus (which in most situations it will have by virtue of being
> raised).

But see above.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11566@debbugs.gnu.org>
> Date: Tue, 29 May 2012 12:15:51 -0700
> 
> > > In something like `select-frame-set-input-focus', my 
> > > interpretation was that frame selection was related to the
> > > border highlighting and setting input focus
> > > was related to receiving keyboard input.  AFAIK, 
> > > `select-frame' does the former, but `select-frame-set-input-focus'
> > > is needed to get the latter.
> > 
> > On Windows, at least with the default setup, selecting a frame also
> > grabs focus.  So these two functions do the same.
> 
> No, definitely not with my (non-default) setup.  Selecting a frame does not give
> it the input focus.

Not even in "emacs -Q"?  IOW, is this an Emacs setup issue, or a
Windows setup issue?

> Hence my need to call `select-frame-set-input-focus' in a few places.  And, I
> would guess, hence the existence of two different functions: `select-frame' and
> `s-f-s-i-f'.

My guess is that they exist because on X the situation is quite
different: X defaults (or at least used to) to "pointer to focus", not
"click to focus".

> I'm no expert on any of this, obviously.

Unfortunately, neither am I.  I just read a bit about this for the
last few days, because apparently no one else wanted to work on bug
#11513.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11566@debbugs.gnu.org>
> Date: Tue, 29 May 2012 12:15:26 -0700
> 
> When `dired-mark-pop-up' calls `dired-pop-to-buffer' (inside a
> `save-window-excursion', a new frame is created (to show the *Marked Files*).  
> 
> The new frame gets the input focus, and its border is highlighted.  Can't tell
> about the stacking order, since my standalone minibuffer frame does not overlap
> it.

This part is clear, but would it be possible for you to arrange the
windows so that the stacking order is also apparent?

> Then when `dired-mark-pop-up' calls `read-from-minibuffer' immediately
> thereafter, the input focus remains where it was, and likewise the border
> highlighting.

I understand that read-from-minibuffer pops up a minibuffer frame, or
at least it should.  Does that frame become the topmost in the
stacking order after read-from-minibuffer is called, or does it stay
below other windows, like it was before the call to
read-from-minibuffer?

Thanks.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> > > On Windows, at least with the default setup, selecting a 
> > > frame also grabs focus.  So these two functions do the same.
> > 
> > No, definitely not with my (non-default) setup.  Selecting 
> > a frame does not give it the input focus.
> 
> Not even in "emacs -Q"?  IOW, is this an Emacs setup issue, or a
> Windows setup issue?

I don't know what the test recipe would be.

I don't know what it is for my setup either.  All I know is that I have had to
add calls to `select-frame-set-input-focus', and that `select-frame' did not do
the trick.

And I don't say that `select-frame' _never_ gives focus to the frame it selects.
I'm saying only that in some situations I have had to use `s-f-s-i-p'.

Typically, IIRC, this has been necessary when using the minibuffer, and, e.g. a
key in the minibuffer map caused a new frame to be created or (correctly) caused
some action to take place in another frame.  In such situations I need to call
`s-f-s-i-f' to the standalone minibuffer frame in order to continue with
minibuffer input (e.g. completion).  `select-frame' does not cut the mustard
here.

> > Hence my need to call `select-frame-set-input-focus' in a 
> > few places.  And, I would guess, hence the existence of two 
> > different functions: `select-frame' and `s-f-s-i-f'.
> 
> My guess is that they exist because on X the situation is quite
> different: X defaults (or at least used to) to "pointer to focus", not
> "click to focus".

Could be.  But as I say, `select-frame' did not seem to do the job, which is why
I moved on to `s-f-s-i-f', which did.

> > I'm no expert on any of this, obviously.
> 
> Unfortunately, neither am I.  I just read a bit about this for the
> last few days, because apparently no one else wanted to work on bug
> #11513.

Thank you for your efforts.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]

> > The new frame gets the input focus, and its border is 
> > highlighted.  Can't tell about the stacking order,
> > since my standalone minibuffer frame does not overlap it.
> 
> This part is clear, but would it be possible for you to arrange the
> windows so that the stacking order is also apparent?

OK, I've done that.

A couple of things to say, but I'm not sure this will make things clearer.

In some cases, the new frame does not take the input focus.  In the case I was
reporting, it does.  Unfortunately, the code to reproduce this would be too much
to ask others to load etc.

What I can say about the stacking order is this: Regardless of which frame gets
the input focus, the minibuffer frame is on top (foremost, most raised). And any
echoing to the echo area also moves it to the top (regardless of where the input
focus is).

Being on top, having the input focus, and having the borders highlighted all
seem to be independent (not necessarily coupled).

> > Then when `dired-mark-pop-up' calls `read-from-minibuffer' 
> > immediately thereafter, the input focus remains where it
> > was, and likewise the border highlighting.
> 
> I understand that read-from-minibuffer pops up a minibuffer frame, or
> at least it should.  

Not quite.  With a standalone minibuffer frame, the frame is not popped up - it
is always there.  But yes, the minibuffer becomes active/inactive (there just is
no "popping up").

> Does that frame become the topmost in the
> stacking order after read-from-minibuffer is called, or does it stay
> below other windows, like it was before the call to
> read-from-minibuffer?

I believe now that any activation of the minibuffer, and even any use of the
echo area, raises the minibuffer frame to the front.

HTH.  Sorry it would be so difficult to enable you to reproduce the problem -
you would need to load a few libraries etc.

What I can say about it is this:

If I mark some files in Dired and do `M' (`dired-do-chmod') to change their
mode, then the *Marked Files* frame is popped up, but the minibuffer frame
retains the focus when the chmod value is read (and is on top).

But if I mark some files and a subdir, and I use my command
`diredp-do-chmod-recursive', then things are different.  This is like
`dired-do-chmod' but it acts on all of the files that are marked, plus all of
the files that are marked in any Dired buffers for marked subdirs, recursively.
Then it does what `M' does on that list of files.

But before popping up `*Marked Files*' etc. it (1) asks you for confirmation of
the recursive operation and then, (2) if there are such Dired buffers for marked
subdirs (recursively), asks you whether to use them.  (The alternative here is
to act on all files of the marked subdirs, determined recursively.)

After you answer these questions, `*Marked Files*' is popped up and you are
asked for the chmod value (e.g. `go+w').  It is for that last input reading that
the problem arises: the input focus is in the *Marked Files* frame.  This is the
call to `read-from-minibuffer' that comes from `dired-mark-pop-up' just after it
called `dired-pop-to-buffer' to pop up `*Marked Files*'.

But this is the same code sequence that occurs for `M' - AFAICT the only
difference is the existence of the two preliminary questions.  So it's not clear
to me where the problem comes from.  This is the calling sequence:

dired-do-chmod OR diredp-do-chmod-recursive
> dired-mark-read-string
> dired-mark-pop-up
> dired-pop-to-buffer
> make-frame, then read-from-minibuffer (via FUNCTION arg)

The code for `dired-do-chmod' and `diredp-do-chmod-recursive' is nearly
identical - see attachment.  The only difference is the gathering of the list of
files (which includes the preliminary confirmation questions).

[-- Attachment #2: throw-chmod-vs-chmod-rec.el --]
[-- Type: application/octet-stream, Size: 2955 bytes --]

;; Vanilla Emacs `dired-do-chmod':

(defun dired-do-chmod (&optional arg)
  "Change the mode of the marked (or next ARG) files.
Symbolic modes like `g+w' are allowed."
  (interactive "P")
  (let* ((files (dired-get-marked-files t arg))
	 (modestr (and (stringp (car files))
		       (nth 8 (file-attributes (car files)))))
	 (default
	   (and (stringp modestr)
		(string-match "^.\\(...\\)\\(...\\)\\(...\\)$" modestr)
		(replace-regexp-in-string
		 "-" ""
		 (format "u=%s,g=%s,o=%s"
			 (match-string 1 modestr)
			 (match-string 2 modestr)
			 (match-string 3 modestr)))))
	 (modes (dired-mark-read-string
		 "Change mode of %s to: "
		 nil 'chmod arg files default))
	 num-modes)
    (cond ((equal modes "")
	   ;; We used to treat empty input as DEFAULT, but that is not
	   ;; such a good idea (Bug#9361).
	   (error "No file mode specified"))
	  ((string-match "^[0-7]+" modes)
	   (setq num-modes (string-to-number modes 8))))

    (dolist (file files)
      (set-file-modes
       file
       (if num-modes num-modes
	 (file-modes-symbolic-to-number modes (file-modes file)))))
    (dired-do-redisplay arg)))


;; `diredp-do-chmod-recursive':
(defun diredp-do-chmod-recursive (&optional ignore-marks-p) ; Bound to `M-+ M'
  "Change the mode of the marked files, including those in marked subdirs.
Symbolic modes like `g+w' are allowed.
Note that marked subdirs are not changed.  Their markings are used
only to indicate that some of their files are to be changed."
  (interactive (progn (diredp-get-confirmation-recursive)
                      (list current-prefix-arg)))
  (let* ((files    (diredp-get-files ignore-marks-p))
         (modestr  (and (stringp (car files))
                        (nth 8 (file-attributes (car files)))))
         (default  (and (stringp modestr)
                        (string-match "^.\\(...\\)\\(...\\)\\(...\\)$" modestr)
                        (replace-regexp-in-string "-" "" (format "u=%s,g=%s,o=%s"
                                                                 (match-string 1 modestr)
                                                                 (match-string 2 modestr)
                                                                 (match-string 3 modestr)))))
         (modes    (dired-mark-read-string "Change mode of marked files here and below to: "
                                           nil 'chmod nil files default)))
    (when (equal modes "") (error "No file mode specified"))
    (dolist (file  files)
      (set-file-modes file (or (and (string-match "^[0-7]+" modes)
                                    (string-to-number modes 8))
                               (file-modes-symbolic-to-number modes (file-modes file)))))
    (diredp-do-redisplay-recursive 'MSGP)))

;; For the code for `diredp-get-confirmation-recursive' and `diredp-get-files', see here:
;; http://www.emacswiki.org/emacs/download/dired%2b.el

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11566@debbugs.gnu.org>
> Date: Tue, 29 May 2012 14:31:39 -0700
> 
> Being on top, having the input focus, and having the borders highlighted all
> seem to be independent (not necessarily coupled).

Yes, that's true.

> After you answer these questions, `*Marked Files*' is popped up and you are
> asked for the chmod value (e.g. `go+w').  It is for that last input reading that
> the problem arises: the input focus is in the *Marked Files* frame.

Is the input focus there, or does the input you type arrive at that
frame (instead of the minibuffer frame)?  As we established, the frame
that has focus and the frame that gets the input can be different
frames, thanks to redirect-frame-focus.

I see in the code that read-from-minibuffer (or, rather, one of its
subroutines) does the equivalent of the following:

   (if minibuffer-auto-raise
       (raise-frame minibuffer-frame))
   ...
   (or (eq (selected-frame) minibuffer-frame)
       (redirect-frame-focus minibuffer-frame))

Does your setup have minibuffer-auto-raise set to a non-nil value?  If
not, can you see if setting it non-nil fixes the problem?  (I'm not
saying that this should be the fix, I'm just trying to figure out
which part(s) of read-from-minibuffer fail to do their job.)

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> > After you answer these questions, `*Marked Files*' is 
> > popped up and you are asked for the chmod value (e.g. `go+w').
> > It is for that last input reading that the problem arises:
> > the input focus is in the *Marked Files* frame.
> 
> Is the input focus there, or does the input you type arrive at that
> frame (instead of the minibuffer frame)?  As we established, the frame
> that has focus and the frame that gets the input can be different
> frames, thanks to redirect-frame-focus.

Guess I'm still not clear on the difference.  I thought that they were the same.

What I see is that the minibuffer receives no input - that's the problem.  The
input you type goes to the other frame.

How to know which frame has the input focus if it is not the frame that receives
the input you type?

> Does your setup have minibuffer-auto-raise set to a non-nil value?

It is t.  I think that is probably typical for someone who uses a standalone
minibuffer frame, but I don't know.

bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[martin rudalics]

 > OK, so what happens is this: When `read-from-minibuffer' does its thing,
 > the standalone minibuffer does not receive the user input.  Instead, the
 > input goes to the popped-up frame (which has a list of *Marked Files*).

Closing the bug since the behavior should have changed with the latest
changes in `dired-mark-pop-up'.  Feel free to reopen this if it's not
fixed yet.

martin