Re: mouse-autoselect-window

[Jeremy Maitin-Shepard]

martin rudalics <address@hidden> writes:

>> My take on `focus-follows-mouse' is that it tells Emacs that it can make
>> use of the hack of warping the mouse pointer in order to change the
>> window manager frame focus.  With a click-to-focus window manager, this
>> hack is not available, and consequently Emacs may be unable to change
>> the window manager focus.

> Do you mean that whether Emacs is able to warp the mouse pointer depends
> on the policy of the window manager too?

No, Emacs will be able to warp the mouse, but it won't have the intended
effect of focusing the frame.  In general, normal programs should not
warp the mouse, but it may be reasonable for the window manager to warp
the mouse (e.g. if a different top-level window is focused using a
keyboard command or by some other programmatic method.)

>> There is not really any completely correct way for Emacs to switch to a
>> different frame.  Using XSetInputFocus certainly is not the correct way
>> at all, because (a) window managers are likely to actively prevent such
>> uses, since clients often misuse it,

> ... wouldn't this argument apply to a focus-follows-mouse policy too?

Yes, even with a focus-follows-mouse window manager, there is no
absolutely correct way to switch to a different frame; warping the mouse
just improves the changes of succeeding in certain circumstances.

>> and (b) it doesn't work if the
>> window to which focus will be transfered is unmapped (iconified), which
>> may be the case if the window manager has iconified it or
>> "shaded/rolled" it, an action that a tiling or tabbing window manager
>> may do routinely.

> We do x_make_frame_invisible in this case.  Would that fail?

I'm not sure what you mean by the reference to x_make_frame_invisible.
It looks like that is used to handle the lisp function
make-frame-invisible, which makes a top-level window "Withdrawn"
(according to the ICCCM spec), a state in which it is not visible and
not managed by the window manager at all.

I am referring to the following issue: Emacs wants to switch focus to a
particular frame e.g. because the user ran the command (next-error) and
the relevant file is already being shown in another frame (the "new
frame").  If the new frame is already visible (i.e. mapped), then one of
the hacks used by (select-frame-set-input-focus) may or may not succeed,
depending on the window manager.  (There is also the issue that
select-frame-set-input-focus is not used in all of the cases that is
should be.)  If, however, the new frame is unmapped and iconified, then
select-frame-set-input-focus definitely will not work.

Note that once a client offers a top-level window to the window manager
to be managed (bringing it out of the Withdrawn state), it will remain
managed by the window manager until the client explicitly moves it to
the withdrawn state.  While it is managed, it will either be in the
visible state, meaning it is mapped (and presumably at least partially
visible), or it will be in the iconic state, and unmapped.  It is the
window manager that decides at all times in which of these two states a
window will be, although a client can request a transition from visible
to iconic or from iconic to visible.  The window manager should mark a
window as iconified whenever it will not be visible for any reason, so
that the client knows that it need not waste any resources redrawing it;
a window should be marked iconified, therefore, when it is
shaded/"rolled up" or not part of the current workspace, or on an
unselected tab, in addition to when the user explicitly "iconifies" it.

In my tiling window manager, for instance, if a new window is opened or
selected, if there is not enough space, the least recently used window
will be automatically shaded/"rolled up", and therefore iconified.  I
would still like it to be possible, though, for emacs to focus an
iconified frame (and cause it to become visible).

The fix is to improve select-window-set-input-focus, so that it uses the
method suggested by the Extended Window Manager Hints document, in
addition to the current methods.

-- 
Jeremy Maitin-Shepard