* pop-to-buffer does not change input focus
@ 2006-04-21 16:59 David Reitter
2006-04-21 17:44 ` Stefan Monnier
2006-04-21 20:57 ` Lars Hansen
0 siblings, 2 replies; 10+ messages in thread
From: David Reitter @ 2006-04-21 16:59 UTC (permalink / raw)
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))
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 16:59 pop-to-buffer does not change input focus David Reitter
@ 2006-04-21 17:44 ` Stefan Monnier
2006-04-21 20:01 ` Lennart Borgman
2006-04-21 20:57 ` Lars Hansen
1 sibling, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2006-04-21 17:44 UTC (permalink / raw)
Cc: Emacs-Devel '
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 17:44 ` Stefan Monnier
@ 2006-04-21 20:01 ` Lennart Borgman
2006-04-21 20:23 ` David Reitter
0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman @ 2006-04-21 20:01 UTC (permalink / raw)
Cc: David Reitter, Emacs-Devel '
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 20:01 ` Lennart Borgman
@ 2006-04-21 20:23 ` David Reitter
0 siblings, 0 replies; 10+ messages in thread
From: David Reitter @ 2006-04-21 20:23 UTC (permalink / raw)
Cc: Stefan Monnier, Emacs-Devel '
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 16:59 pop-to-buffer does not change input focus David Reitter
2006-04-21 17:44 ` Stefan Monnier
@ 2006-04-21 20:57 ` Lars Hansen
2006-04-21 21:06 ` Stefan Monnier
1 sibling, 1 reply; 10+ messages in thread
From: Lars Hansen @ 2006-04-21 20:57 UTC (permalink / raw)
Cc: Emacs-Devel '
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 20:57 ` Lars Hansen
@ 2006-04-21 21:06 ` Stefan Monnier
2006-04-21 22:51 ` Lars Hansen
2006-04-23 19:31 ` Lars Hansen
0 siblings, 2 replies; 10+ messages in thread
From: Stefan Monnier @ 2006-04-21 21:06 UTC (permalink / raw)
Cc: David Reitter, Emacs-Devel '
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 21:06 ` Stefan Monnier
@ 2006-04-21 22:51 ` Lars Hansen
2006-04-23 19:31 ` Lars Hansen
1 sibling, 0 replies; 10+ messages in thread
From: Lars Hansen @ 2006-04-21 22:51 UTC (permalink / raw)
Cc: David Reitter, Emacs-Devel '
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pop-to-buffer does not change input focus
2006-04-21 21:06 ` Stefan Monnier
2006-04-21 22:51 ` Lars Hansen
@ 2006-04-23 19:31 ` Lars Hansen
2006-04-24 17:52 ` Richard Stallman
1 sibling, 1 reply; 10+ messages in thread
From: Lars Hansen @ 2006-04-23 19:31 UTC (permalink / raw)
Cc: David Reitter, Emacs-Devel '
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-04-24 21:27 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-21 16:59 pop-to-buffer does not change input focus David Reitter
2006-04-21 17:44 ` Stefan Monnier
2006-04-21 20:01 ` Lennart Borgman
2006-04-21 20:23 ` David Reitter
2006-04-21 20:57 ` Lars Hansen
2006-04-21 21:06 ` Stefan Monnier
2006-04-21 22:51 ` Lars Hansen
2006-04-23 19:31 ` Lars Hansen
2006-04-24 17:52 ` Richard Stallman
2006-04-24 21:27 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.