pop-to-buffer does not change input focus

pop-to-buffer does not change input focus

[David Reitter]

With `pop-up-frames' set to t, `pop-to-buffer' will show a new frame  
with the buffer given. But if a frame showing that buffer already  
exists, this buffer is selected, the frame is raised, but it does not  
get input focus. This leads to situations where the frame is opened  
on top of the old one, but any input events go to the old one.

Either way, it is inconsistent with respect to the behavior you get  
when `pop-up-frames' is nil, `pop-up-windows' is t, and the buffer is  
shown in a new window. In that case, the window is always selected  
and the frame has input focus anyways, hence any input will go there.

The code below demonstrates the problem. A new frame with a new  
buffer is created, then we switch back to the old one. The final call  
to `pop-to-buffer' then doesn't set input focus.

This may not so evident in configurations where X is used and "focus  
follows mouse", because the user doesn't expect the system to select  
another frame without the mouse being moved (actively). It is less  
problem when new frames don't appear on top of the old ones. However,  
it is still inconsistent, and setting pop-up-frames to t will break  
the workflow in a lot of cases, where we expect the input to continue  
in the target buffer. Consider M-x compose-mail.


I suggest that `pop-to-buffer' should contain a call to something  
like `select-frame-set-input-focus'.


====
Code:


(let ((orig-window (selected-window))
       (orig-frame (selected-frame))
       (new-buf (generate-new-buffer "*test*"))
       (focus-follows-mouse nil) ;; to demonstrate the effect on X
       ;; move mouse out of the way on X
       )

   ;; the following command should set the input focus, but it doesn't
   ;; the result is a raised second frame, with the input focus back
   ;; in the old buffer.
   (let ((pop-up-windows nil)
	(pop-up-frames t))
     (pop-to-buffer new-buf)
     (select-frame-set-input-focus orig-frame) ;; switch back to old  
frame
     (pop-to-buffer new-buf))
   (current-buffer))

Re: pop-to-buffer does not change input focus

[Stefan Monnier]

> With `pop-up-frames' set to t, `pop-to-buffer' will show a new frame  with
> the buffer given. But if a frame showing that buffer already  exists, this
> buffer is selected, the frame is raised, but it does not  get input
> focus. This leads to situations where the frame is opened  on top of the old
> one, but any input events go to the old one.

Sounds like a bug.  Please use M-x report-emacs-bug for such reports.
It also sounds like a bug that might depend on the window-manager or
window-system.


        Stefan

Re: pop-to-buffer does not change input focus

[Lennart Borgman]

Stefan Monnier wrote:
>> With `pop-up-frames' set to t, `pop-to-buffer' will show a new frame  with
>> the buffer given. But if a frame showing that buffer already  exists, this
>> buffer is selected, the frame is raised, but it does not  get input
>> focus. This leads to situations where the frame is opened  on top of the old
>> one, but any input events go to the old one.
>>     
>
> Sounds like a bug.  Please use M-x report-emacs-bug for such reports.
> It also sounds like a bug that might depend on the window-manager or
> window-system.
>
>
>         Stefan
>   

I just tested this on w32 (CVS Emacs from 2006-04-09, unpatched) and 
there the test buffer *test* gets input focus as it should.

Re: pop-to-buffer does not change input focus

[David Reitter]

On 21 Apr 2006, at 21:01, Lennart Borgman wrote:
>>
>> Sounds like a bug.  Please use M-x report-emacs-bug for such reports.
>> It also sounds like a bug that might depend on the window-manager or
>> window-system.
>>
>>
>>         Stefan
>>
>
> I just tested this on w32 (CVS Emacs from 2006-04-09, unpatched)  
> and there the test buffer *test* gets input focus as it should.

I tested it on Mac OS X (Carbon port, current, see below) and on an  
X11 based GNU/Linux system (CVS, older) with the Apple X11 X Server.





In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
of 2006-04-21 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.6
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   encoded-kbd-mode: t
   tooltip-mode: t
   auto-compression-mode: t
   tool-bar-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   line-number-mode: t

Recent input:
<escape> x r e p o r t - e m <tab> <return>

Recent messages:
(/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs -Q)
Loading encoded-kb...done
Loading emacsbug...done

Re: pop-to-buffer does not change input focus

[Lars Hansen]

David Reitter wrote:

> With `pop-up-frames' set to t, `pop-to-buffer' will show a new frame 
> with the buffer given. But if a frame showing that buffer already 
> exists, this buffer is selected, the frame is raised, but it does not 
> get input focus.

I can confirm it, on Debian stable with Gnome and with an Emacs checked
out and compiled a couple of hours ago started with -Q.
And display-buffer has the same problem.

Reading the code of Fdisplay_buffer, it seem to me that it ends up
calling Fraise_frame which calls Fmake_frame_visible. So maybe theses
functions has a problem. This is what I see:

1. If a frame is hidden (partly or completely) behind the selected
frame, raise-frame brings it to the top but it does not get input focus.
2. If a frame is hidden (partly or completely) behind the selected
frame, make-frame-visible does nothing!
3. If a frame is iconified, raise-frame as well as make-frame-visible
deiconifies it but it ends up behind the selected frame and it does not
get input focus.

BTW, are raise-frame and make-frame-visible supposed to give input focus
to the frame? The doc strings say nothing. And what is really the
difference between these two functions?

Re: pop-to-buffer does not change input focus

[Stefan Monnier]

> Reading the code of Fdisplay_buffer, it seem to me that it ends up
> calling Fraise_frame which calls Fmake_frame_visible. So maybe theses
> functions has a problem. This is what I see:

I think this is all OK: display-buffer is not supposed to select the
corresponding window/frame.
But in Fpop_to_buffer, we call Fselect_window on the window just displayed
by Fdisplay_buffer and *that* should cause the input focus to be set.

> BTW, are raise-frame and make-frame-visible supposed to give input focus
> to the frame?

Not that I know.

> The doc strings say nothing. And what is really the difference between
> these two functions?

A frame's visibility can be "invisible", "iconified", or "visible", and
make-frame-visible only influences this.  So it doesn't raise the frame.


        Stefan

Re: pop-to-buffer does not change input focus

[Lars Hansen]

Stefan Monnier wrote:

>I think this is all OK: display-buffer is not supposed to select the
>corresponding window/frame.
>But in Fpop_to_buffer, we call Fselect_window on the window just displayed
>by Fdisplay_buffer and *that* should cause the input focus to be set.
>  
>
Ok, I was on a wrong track.
My test verifies that Fselect_window does not set the input focus.

Re: pop-to-buffer does not change input focus

[Lars Hansen]

Stefan Monnier wrote:

>But in Fpop_to_buffer, we call Fselect_window on the window just displayed
>by Fdisplay_buffer and *that* should cause the input focus to be set.
>  
>
I don't think Fselect_window is supposed to set the input focus. AFAICS
from reading section 29.9 in the Emacs Lisp Manual (Input Focus), the
only lisp function that changes input focus is select-frame-set-input-focus.
The reason why the frame selected by pop-to-buffer gets input focus when
it is newly created but not when it existed already, is because newly
created frames get input focus (at least under my test test conditions
(GNU/Linux with Gnome)), whereas frames just raised don't.

IHMO this is confusing. Why don't select-frame set the input focus?

Re: pop-to-buffer does not change input focus

[Richard Stallman]

    IHMO this is confusing. Why don't select-frame set the input focus?

I recall there was a good reason for this.  Perhaps the reason
is that Emacs programs often call select-frame for internal reasons
and this should not cause a focus change.

Please don't take the risk of messing with this now.

Re: pop-to-buffer does not change input focus

[Stefan Monnier]

>     IHMO this is confusing. Why don't select-frame set the input focus?
> I recall there was a good reason for this.  Perhaps the reason
> is that Emacs programs often call select-frame for internal reasons
> and this should not cause a focus change.

Very good point.  Hmm... now I'm not sure where the set-focus should take
place,


        Stefan