Re: mouse-autoselect-window

Re: mouse-autoselect-window

[Jason Rumney]

Michael Kifer wrote:
> This is independent of focus-follows-mouse. Almost all users want the mouse
> to be warped into the control window regardless of their preferences about
> how the focus is handled by the window manager.
>   

Really? Have you done a poll of users to come to this conclusion? What
purpose does warping the mouse serve in the non focus-follows-mouse case?

Re: mouse-autoselect-window

[Michael Kifer]

> Michael Kifer wrote:
> > This is independent of focus-follows-mouse. Almost all users want the mouse
> > to be warped into the control window regardless of their preferences about
> > how the focus is handled by the window manager.
> >   
> 
> Really? Have you done a poll of users to come to this conclusion? What

In 10+ years nobody complained.

> purpose does warping the mouse serve in the non focus-follows-mouse case?

In the non focus-follows-mouse case warping is not necessary.
But then it also does not matter where the mouse is.

Re: mouse-autoselect-window

[Jason Rumney]

> In 10+ years nobody complained.
>   

Not complaining is not the same as wanting it that way.

>> purpose does warping the mouse serve in the non focus-follows-mouse case?
>>     
>
> In the non focus-follows-mouse case warping is not necessary.
> But then it also does not matter where the mouse is.
>   

I propose we change the default value of ediff-grab-mouse from t to the
value of focus-follows-mouse.
Since it can take a value of 'maybe, it cannot simply be made an alias.

mouse-autoselect-window

[Drew Adams]

I just stumbled upon `mouse-autoselect-window' and I wonder how it is
supposed to work - in particular, on MS Windows. The doc is pretty skimpy.

Trying it out with a value of t, it seems to make the focus follow the
mouse, as long as you stay within the same frame.

When you move the mouse to a different frame, the mode line is activated,
and the menu-bar and the tool-bar icons change (depending on the buffer),
giving the impression that the focus has shifted to the window under the
mouse in the new frame. But the focus remains in the last window the mouse
was in in the old frame. The frame border and title bar of the old frame
show that it still has the focus; it is only the mode line, menu-bar, and
tool bar that indicate (falsely) the contrary.

IIUC, on MS Windows there is no way for Emacs to override the
click-to-focus-frame behavior. In that case, should the mode line etc.
really indicate that the focus was moved to the other frame? Am I missing
something - is there some sense in which the new window (in the new frame)
is focused or active? If not, why activate its mode line etc.?

Also, wouldn't it be good to document both `mouse-autoselect-window' and
`focus-follows-mouse' in the same section of the Emacs manual - or at least
provide a cross reference? It's not obvious that both variables exist when
you read about one, and it's not obvious what relation there might be
between them - how each relates to focus.

Finally, shouldn't the doc string for `focus-follows-mouse' make it clear
that it is about _frames_? It does mention "window manager", but that's
about it.

Re: mouse-autoselect-window

[Robert J. Chassell]

Re `mouse-autoselect-window' on a Microsoft operating system

    When you move the mouse to a different frame ... the focus remains
    in the last window the mouse was in in the old frame.

`mouse-autoselect-window' works fine on a GNU/Linux Debian testing
operating system updated this morning, using this morning's CVS of GNU
Emacs, Wed, 2007 Sep 5 09:58 UTC,

By `works fine', I mean, focus follows mouse from one frame to another
and, on both windows I tested, into another window in the same frame.

I have been using `mouse-autoselect-window' successfully for a long
time in instances of GNU Emacs on a free operating system.  It looks
like a bug in the restricted code.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: mouse-autoselect-window

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Re `mouse-autoselect-window' on a Microsoft operating system
>
>     When you move the mouse to a different frame ... the focus remains
>     in the last window the mouse was in in the old frame.
>
> `mouse-autoselect-window' works fine on a GNU/Linux Debian testing
> operating system updated this morning, using this morning's CVS of GNU
> Emacs, Wed, 2007 Sep 5 09:58 UTC,
>
> By `works fine', I mean, focus follows mouse from one frame to another
> and, on both windows I tested, into another window in the same frame.

Do you have a window manager with a click-to-focus policy (and an
according setting of focus-follows-mouse to nil)?  Because if you
don't, you are comparing apples and oranges.

> I have been using `mouse-autoselect-window' successfully for a long
> time in instances of GNU Emacs on a free operating system.  It looks
> like a bug in the restricted code.

Only if you use click-to-focus in your window manager.  Anyway, it
sounds to me like mouse-autoselect-window in connection with
click-to-focus would be a rather useless setting, anyway.  So the
problem appears more like a user configuration error than anything
else.

-- 
David Kastrup

Re: mouse-autoselect-window

[Stephen Berman]

On Wed, 05 Sep 2007 12:49:27 +0200 David Kastrup <dak@gnu.org> wrote:

> "Robert J. Chassell" <bob@rattlesnake.com> writes:
>
>> Re `mouse-autoselect-window' on a Microsoft operating system
>>
>>     When you move the mouse to a different frame ... the focus remains
>>     in the last window the mouse was in in the old frame.
>>
>> `mouse-autoselect-window' works fine on a GNU/Linux Debian testing
>> operating system updated this morning, using this morning's CVS of GNU
>> Emacs, Wed, 2007 Sep 5 09:58 UTC,
>>
>> By `works fine', I mean, focus follows mouse from one frame to another
>> and, on both windows I tested, into another window in the same frame.
>
> Do you have a window manager with a click-to-focus policy (and an
> according setting of focus-follows-mouse to nil)?  Because if you
> don't, you are comparing apples and oranges.
>
>> I have been using `mouse-autoselect-window' successfully for a long
>> time in instances of GNU Emacs on a free operating system.  It looks
>> like a bug in the restricted code.
>
> Only if you use click-to-focus in your window manager.  Anyway, it
> sounds to me like mouse-autoselect-window in connection with
> click-to-focus would be a rather useless setting, anyway.  So the
> problem appears more like a user configuration error than anything
> else.

I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
click-to-focus policy but also have mouse-autoselect-window set to t,
because I want to have autoselection between split windows within a
single frame.  I also observe the same behavior that Drew Adams
described.

Steve Berman

Re: mouse-autoselect-window

[Robert J. Chassell]

The original post described a desire to shift automatically from frame
to frame.  You can only do that with a focus-follows-mouse policy.

When you have a click-to-focus policy in your window manager, I would
expect having to click on a new frame -- I do not expect an instance
of Emacs within a window manager to govern an enclosing window
manager.

That may be our difference.

The documentation for   mouse-autoselect-window  says

    Non-nil means autoselect window with mouse pointer.

and does not refer to frames at all, so I would not expect to select a
different frame unless I had focus-follows-mouse policy.

Try auto-selecting an Emacs window in another frame when you have a
focus-follows-mouse policy turned on.  Of course, the action may be
the window manager's doing.

Indeed, I suspect it is; it does not matter, since it shows that some
one can shift automatically from frame to frame.

I cannot doing anything for window managers that are limited in their
focus policies.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: mouse-autoselect-window

[Drew Adams]

> The original post described a desire to shift automatically from frame
> to frame.

No, it did not. I simply asked some questions and reported an apparent doc
problem and perhaps a difference in behavior on MS Windows. I never said
anything about wanting the focus to follow the mouse across frames.

However, now that you bring it up, I would like to be able to do that ;-).

> You can only do that with a focus-follows-mouse policy.

Is there such a "policy" from within Emacs? I thought that
`focus-follows-mouse' was only to let Emacs know how the window mgr behaves,
not to prescribe a focus behavior (e.g. for the window manager). Here is
what the doc string says:

 You should set this variable to tell Emacs how your window manager
 handles focus, since there is no way in general for Emacs to find out
 automatically.

I've never seen it explained anywhere what Emacs does with that information,
however, or why it needs it...

> When you have a click-to-focus policy in your window manager, I would
> expect having to click on a new frame -- I do not expect an instance
> of Emacs within a window manager to govern an enclosing window
> manager.

That's more or less my understanding also. That seems to contradict what you
said above, though, about focus-follows-mouse letting one shift
automatically from frame to frame.

> That may be our difference.

I don't know that we have a difference - in point of view. We are using
different platforms, however, so that is one difference we have.

> The documentation for   mouse-autoselect-window  says
>
>     Non-nil means autoselect window with mouse pointer.
>
> and does not refer to frames at all, so I would not expect to select a
> different frame unless I had focus-follows-mouse policy.

If the window with the mouse pointer is in a different frame, then that
sentence implies that that window will be autoselected. The sentence does
not limit itself in any way to windows within the same frame, so it applies
to all windows. Whenever a window is selected, so is its frame.

But the window in the other frame is not, in fact, autoselected in MS
Windows. So the doc is not accurate in this case.

> Try auto-selecting an Emacs window in another frame when you have a
> focus-follows-mouse policy turned on.  Of course, the action may be
> the window manager's doing.

`focus-follows-mouse' has no effect in MS Windows, according to the doc and
to my experience.

> Indeed, I suspect it is; it does not matter, since it shows that some
> one can shift automatically from frame to frame.

? Howzat?

> I cannot doing anything for window managers that are limited in their
> focus policies.

You mean that Mr Gates doesn't follow your focus? ;-)

BTW, `mouse-autoselect-window' _could_ select the mouse window in MS
Windows, even on another frame, at the cost of also raising that frame -
just add `select-frame-set-input-focus' to its code. However, I'm not sure
that is a good idea.  I assume that on GNU/Linux etc. the focus moves but
the window is not raised - that's the behavior I would prefer, anyway.

Re: mouse-autoselect-window

[Jason Rumney]

Drew Adams wrote:
> `focus-follows-mouse' has no effect in MS Windows, according to the doc and
> to my experience.
>   

The doc is wrong, and should be changed.

focus-follows-mouse has the same effect on Windows as on any other
system. AFAICT the only effect is that when set, the mouse gets moved to
the newly focused frame when the focussed frame is changed
programatically (so that the window manager honors the focus change).
You can see this with ediff for example.

RE: mouse-autoselect-window

[Drew Adams]

> > `focus-follows-mouse' has no effect in MS Windows, according to
> > the doc and to my experience.
>
> The doc is wrong, and should be changed.
>
> focus-follows-mouse has the same effect on Windows as on any other
> system. AFAICT the only effect is that when set, the mouse gets moved to
> the newly focused frame when the focussed frame is changed
> programatically (so that the window manager honors the focus change).
> You can see this with ediff for example.

1. I'm not 100% sure I understand you. I guess you mean that if, for
example, some code does `select-frame-set-input-focus', then the mouse
pointer will be moved to the newly selected frame. Is that right?

That's certainly true. But if that is the only intended effect of
`focus-follows-mouse', then I'd say that this option should be named
`mouse-follows-focus', not the reverse. IOW, what you describe (and what I
see) is that _if_ the focus is changed to another frame _then_ the mouse is
warped to that frame.

2. Also, people often say, rightly or wrongly, that `focus-follows-mouse' is
useless, inappropriate, ineffective etc. for use with window managers that
impose a click-frame-to-focus policy. If the only intended effect of
`focus-follows-mouse' is what you say it is, then these (common) statements
are off the mark, and whatever window manager policy one has would appear to
be irrelevant.

Re: mouse-autoselect-window

[martin rudalics]

 > 1. I'm not 100% sure I understand you. I guess you mean that if, for
 > example, some code does `select-frame-set-input-focus', then the mouse
 > pointer will be moved to the newly selected frame. Is that right?
 >
 > That's certainly true. But if that is the only intended effect of
 > `focus-follows-mouse', then I'd say that this option should be named
 > `mouse-follows-focus', not the reverse. IOW, what you describe (and what I
 > see) is that _if_ the focus is changed to another frame _then_ the mouse is
 > warped to that frame.

It's needed to avoid that a window-manager with focus-follows-mouse
policy inadvertently reselects the old frame when you move the mouse the
first time after `select-frame-set-input-focus'.

Re: mouse-autoselect-window

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>> 1. I'm not 100% sure I understand you. I guess you mean that if, for
>> example, some code does `select-frame-set-input-focus', then the mouse
>> pointer will be moved to the newly selected frame. Is that right?
>>
>> That's certainly true. But if that is the only intended effect of
>> `focus-follows-mouse', then I'd say that this option should be named
>> `mouse-follows-focus', not the reverse. IOW, what you describe (and what I
>> see) is that _if_ the focus is changed to another frame _then_ the mouse is
>> warped to that frame.
>
> It's needed to avoid that a window-manager with focus-follows-mouse
> policy inadvertently reselects the old frame when you move the mouse the
> first time after `select-frame-set-input-focus'.

On the other hand, naming the option after what it does rather than
the window manager interaction it is intended for might indeed make it
more obvious.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mouse-autoselect-window

[Jason Rumney]

David Kastrup wrote:
> On the other hand, naming the option after what it does rather than
> the window manager interaction it is intended for might indeed make it
> more obvious.
>   

But a change has just been made to do something additional with that
variable. And in future, someone may find another case where the
intuitive behaviour for the focus follow mouse case differs from the
click to focus case. Should they then rename the variable again, or
create a new variable for that single behaviour as well?

RE: mouse-autoselect-window

[Davis Herring]

> 1. I'm not 100% sure I understand you. I guess you mean that if, for
> example, some code does `select-frame-set-input-focus', then the mouse
> pointer will be moved to the newly selected frame. Is that right?
>
> That's certainly true. But if that is the only intended effect of
> `focus-follows-mouse', then I'd say that this option should be named
> `mouse-follows-focus', not the reverse. IOW, what you describe (and what I
> see) is that _if_ the focus is changed to another frame _then_ the mouse
> is
> warped to that frame.

The variable is called `focus-follows-mouse' because it's telling Emacs
whether the window manager has that policy or not.  What Emacs -does- with
that information is supposed to be automatic, perhaps invisible, and in
general The Right Thing.  Somewhat like `enable-flow-control' which does
not cause Emacs to -use- ^S and ^Q (the characters) but rather provide
alternatives for C-s and C-q (the keys).  Calling it
`follow-focus-with-mouse' as a command to Emacs (like `use-file-dialog')
would prevent us from making other useful decisions for the user based on
the window manager policy.

> 2. Also, people often say, rightly or wrongly, that `focus-follows-mouse'
> is
> useless, inappropriate, ineffective etc. for use with window managers that
> impose a click-frame-to-focus policy. If the only intended effect of
> `focus-follows-mouse' is what you say it is, then these (common)
> statements
> are off the mark, and whatever window manager policy one has would appear
> to
> be irrelevant.

`focus-follows-mouse' is input to Emacs about the window-manager.  It is
inappropriate when the policy is click-to-focus because you are telling
Emacs something that is -false-.  Conversely, the policy is certainly
relevant in that if you have point-to-focus but Emacs doesn't know that,
it may leave the mouse somewhere that causes the wrong thing to happen
when it tries to raise frames, switch frames, etc.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: mouse-autoselect-window

[Jeremy Maitin-Shepard]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > `focus-follows-mouse' has no effect in MS Windows, according to
>> > the doc and to my experience.
>> 
>> The doc is wrong, and should be changed.
>> 
>> focus-follows-mouse has the same effect on Windows as on any other
>> system. AFAICT the only effect is that when set, the mouse gets moved to
>> the newly focused frame when the focussed frame is changed
>> programatically (so that the window manager honors the focus change).
>> You can see this with ediff for example.

> 1. I'm not 100% sure I understand you. I guess you mean that if, for
> example, some code does `select-frame-set-input-focus', then the mouse
> pointer will be moved to the newly selected frame. Is that right?

> That's certainly true. But if that is the only intended effect of
> `focus-follows-mouse', then I'd say that this option should be named
> `mouse-follows-focus', not the reverse. IOW, what you describe (and what I
> see) is that _if_ the focus is changed to another frame _then_ the mouse is
> warped to that frame.

> 2. Also, people often say, rightly or wrongly, that `focus-follows-mouse' is
> useless, inappropriate, ineffective etc. for use with window managers that
> impose a click-frame-to-focus policy. If the only intended effect of
> `focus-follows-mouse' is what you say it is, then these (common) statements
> are off the mark, and whatever window manager policy one has would appear to
> be irrelevant.

The following applies to X11:

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.

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, 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.  The best way to switch focus may be to use the method
described in the Extended Window Manager Hints document, namely sending
a _NET_ACTIVE_WINDOW message.  This could perhaps be used in conjunction
with XSetInputFocus and the mouse warping hack, since not all window
managers support the _NET_ACTIVE_WINDOW message.

For MS Windows:

I believe there are standard Windows API functions that can be used to
raise or focus a particular top-level window, and consequently such
hacks as are needed for X11 are not needed for MS Windows.

-- 
Jeremy Maitin-Shepard

Re: mouse-autoselect-window

[Eli Zaretskii]

> From: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
> Date: Thu, 06 Sep 2007 23:28:00 -0400
> Cc: emacs-devel@gnu.org
> 
> For MS Windows:
> 
> I believe there are standard Windows API functions that can be used to
> raise or focus a particular top-level window, and consequently such
> hacks as are needed for X11 are not needed for MS Windows.

That is exactly true, and that's exactly why it is useless to set
focus-follows-mouse on MS-Windows: the w32 support code that handles
frame switches already uses the Windows API that you mentioned.

However, this all is correct for switching frames, and for switching
frames alone.  This thread is about something else: it's about the
code that selects a window, not raises a frame.

Re: mouse-autoselect-window

[martin rudalics]

> That is exactly true, and that's exactly why it is useless to set
> focus-follows-mouse on MS-Windows: the w32 support code that handles
> frame switches already uses the Windows API that you mentioned.

IIUC it wouldn't harm to explicitly move the mouse-pointer there
if focus-follows-mouse is non-nil and the window gets selected
in a programmed way.  Or does the API move the mouse pointer too
when switching frames?

Re: mouse-autoselect-window

[Davis Herring]

>> That is exactly true, and that's exactly why it is useless to set
>> focus-follows-mouse on MS-Windows: the w32 support code that handles
>> frame switches already uses the Windows API that you mentioned.
>
> IIUC it wouldn't harm to explicitly move the mouse-pointer there
> if focus-follows-mouse is non-nil and the window gets selected
> in a programmed way.  Or does the API move the mouse pointer too
> when switching frames?

IIUC it would be -necessary- to do so if point-to-focus were enabled, just
as it is on X with that policy.  So when the user tells us that's the
policy (with `focus-follows-mouse'), we should definitely do so!  (Unless
your last notion about the API is correct, of course.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: mouse-autoselect-window

[Eli Zaretskii]

> Date: Fri, 7 Sep 2007 08:54:28 -0700 (PDT)
> From: "Davis Herring" <herring@lanl.gov>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, drew.adams@oracle.com,
>         "Jeremy Maitin-Shepard" <jeremy@jeremyms.com>, emacs-devel@gnu.org
> 
> > IIUC it wouldn't harm to explicitly move the mouse-pointer there
> > if focus-follows-mouse is non-nil and the window gets selected
> > in a programmed way.  Or does the API move the mouse pointer too
> > when switching frames?
> 
> IIUC it would be -necessary- to do so if point-to-focus were enabled, just
> as it is on X with that policy.

No, it isn't necessary.  The fact that it's necessary on X is because
there's no better way.  But MS-Windows doesn't have that problem, so
there's no need for that kludge.

Re: mouse-autoselect-window

[Davis Herring]

>> IIUC it would be -necessary- to do so if point-to-focus were enabled,
>> just
>> as it is on X with that policy.
>
> No, it isn't necessary.  The fact that it's necessary on X is because
> there's no better way.  But MS-Windows doesn't have that problem, so
> there's no need for that kludge.

If you have point-to-focus enabled, and something programmatically
switches your focus to a window that the mouse is not over, and you move
the mouse (possibly over various windows, perhaps to get back to the
focused window), it doesn't snap focus back to the mouse?  When would it
resume the point-to-focus policy?  Or are you just saying that the focus
doesn't snap back instantaneously, without even mouse movement?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: mouse-autoselect-window

[Eli Zaretskii]

> Date: Fri, 7 Sep 2007 12:46:40 -0700 (PDT)
> From: "Davis Herring" <herring@lanl.gov>
> Cc: rudalics@gmx.at, drew.adams@oracle.com, jeremy@jeremyms.com,
>         emacs-devel@gnu.org
> 
> >> IIUC it would be -necessary- to do so if point-to-focus were enabled,
> >> just
> >> as it is on X with that policy.
> >
> > No, it isn't necessary.  The fact that it's necessary on X is because
> > there's no better way.  But MS-Windows doesn't have that problem, so
> > there's no need for that kludge.
> 
> If you have point-to-focus enabled, and something programmatically
> switches your focus to a window that the mouse is not over, and you move
> the mouse (possibly over various windows, perhaps to get back to the
> focused window), it doesn't snap focus back to the mouse?

No.  As I wrote in reply to Jason's question, focus is switched only
when mouse crosses a frame boundary, just moving it within a frame
that doesn't have focus does not yet give back focus to that frame.

> When would it resume the point-to-focus policy?

"Resume policy" implies that the policy was suspended.  But it wasn't
suspended, it's just that on MS-Windows focus is switched only when
mouse enters or exits a frame, not because the mouse pointer moved.

Re: mouse-autoselect-window

[Jan Djärv]

Eli Zaretskii skrev:

> "Resume policy" implies that the policy was suspended.  But it wasn't
> suspended, it's just that on MS-Windows focus is switched only when
> mouse enters or exits a frame, not because the mouse pointer moved.

This is true for most X window managers also.  But as with all X related 
things, all kinds of implementations exists.

	Jan D.

Re: mouse-autoselect-window

[Jason Rumney]

Eli Zaretskii wrote:
> No, it isn't necessary.  The fact that it's necessary on X is because
> there's no better way.  But MS-Windows doesn't have that problem, so
> there's no need for that kludge.
>   
I'm not convinced Windows magically avoids the problem here. If you use
a focus follows mouse policy on Windows and set focus-follows-mouse to
nil, what happens when you start an ediff session then move the mouse
slightly (keeping it over the main frame)?

Re: mouse-autoselect-window

[Eli Zaretskii]

> Date: Sat, 08 Sep 2007 01:46:43 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: herring@lanl.gov, rudalics@gmx.at, jeremy@jeremyms.com,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> 
> If you use a focus follows mouse policy on Windows and set
> focus-follows-mouse to nil, what happens when you start an ediff
> session then move the mouse slightly (keeping it over the main
> frame)?

(You need to set ediff-grab-mouse to nil as well, without it Ediff
always moves the mouse pointer to the Ediff control frame, which I
think defeats the test you had in mind.)

When I set both focus-follows-mouse and ediff-grab-mouse to nil,
starting an Ediff session switches the focus to the Ediff control
frame, but the mouse pointer stays in the main frame.  Moving the
mouse pointer doesn't change the focus; only if I cross the frame's
boundary the focus switches to another frame.

My conclusion is that on Windows, the "focus follows mouse" policy
(btw, it's called "active window tracking" in MS-Windows parlance) is
triggered only when mouse enters/exits a frame, not when mouse moves.

Re: mouse-autoselect-window

[martin rudalics]

> My conclusion is that on Windows, the "focus follows mouse" policy
> (btw, it's called "active window tracking" in MS-Windows parlance) is
> triggered only when mouse enters/exits a frame, not when mouse moves.

I think you're right for pure "focus follows mouse".  It would be
useful for an "autoraise frame" policy where moving the mouse also
brings the frame under the mouse to the foreground.  Otherwise with
three overlapping frames 1 | 2 | 3 moving the focus from 1 to 3 and
leaving the mouse-pointer in 1 will cause problems when you later
want to move the mouse-pointer to a position in frame 3.  It will
raise frame 2 before you get there and if 2 then hides 3 you will
have to iconify 2 to continue.

Re: mouse-autoselect-window

[Jason Rumney]

Eli Zaretskii wrote:
> (You need to set ediff-grab-mouse to nil as well, without it Ediff
> always moves the mouse pointer to the Ediff control frame, which I
> think defeats the test you had in mind.)
>   
Why does ediff use its own variable for this? What purpose is there in
warping the mouse pointer, besides what focus-follows-mouse already covers?

Re: mouse-autoselect-window

[Eli Zaretskii]

> Date: Fri, 07 Sep 2007 10:58:37 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Jeremy Maitin-Shepard <jeremy@jeremyms.com>,  drew.adams@oracle.com, 
>  emacs-devel@gnu.org
> 
> > That is exactly true, and that's exactly why it is useless to set
> > focus-follows-mouse on MS-Windows: the w32 support code that handles
> > frame switches already uses the Windows API that you mentioned.
> 
> IIUC it wouldn't harm to explicitly move the mouse-pointer there
> if focus-follows-mouse is non-nil and the window gets selected
> in a programmed way.  Or does the API move the mouse pointer too
> when switching frames?

No, the API doesn't do that.  Nor am I convinced it should: after all,
there are reasons to raise a frame other than start typing there, and
Emacs has no way of knowing what the user wants.

Re: mouse-autoselect-window

[martin rudalics]

 > 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?

 > 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?

 > 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?

Re: mouse-autoselect-window

[Jeremy Maitin-Shepard]

martin rudalics <rudalics@gmx.at> 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

Re: mouse-autoselect-window

[martin rudalics]

>>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.

Sorry.  I meant x_make_frame_visible.

> 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.)  

Which cases do you mean here?

> If, however, the new frame is unmapped and iconified, then
> select-frame-set-input-focus definitely will not work.

That's what x_make_frame_visible is supposed to achieve.

> Note that once a client offers a top-level window to the window manager
> to be managed (bringing it out of the Withdrawn state), 

How differs the "withdrawn" from the "iconified" 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).

But it should not make any difference for the client whether the window
was iconified explicitly or just "shaded".

Re: mouse-autoselect-window

[Jan Djärv]

Jeremy Maitin-Shepard skrev:

> 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.
> 

In CVS HEAD, x-focus-frame activates the window the EWMH way.

	Jan D.

Re: mouse-autoselect-window

[Robert J. Chassell]

    > The original post described a desire to shift automatically from
    > frame to frame.

"Drew Adams" <drew.adams@oracle.com> responded

    No, it did not. I simply asked some questions and reported an
    apparent doc problem and perhaps a difference in behavior on MS
    Windows. I never said anything about wanting the focus to follow
    the mouse across frames.

You may not have said that, but since you went from frame to frame but
the variable talks only of windows, I noted that.  It may well be a
doc problem.  I don't know anything about restricted code.

Perhaps Eli can help you.

    ...  about focus-follows-mouse letting one shift automatically
    from frame to frame.

That is a window manager function, not an Emacs function.  I thought I
made that clear.  How did I misstate that?

    >     Non-nil means autoselect window with mouse pointer.

    If the window with the mouse pointer is in a different frame, then
    that sentence ...

The documentation (the sentence after the right angle) does not talk
about frames at all.  So why would you expect a mouse pointer to focus
another frame?

That is a good stylistic question.  I think the sentence is meaningful
and accurate as it stands.  But it seems you interpret it as talking
about shifting frames, too.  I may be misinterpreting you, but if not,
why do you think that?

Also, of course, I can reach all the buffers from a single frame.

    I assume that on GNU/Linux etc. the focus moves but the window is
    not raised - that's the behavior I would prefer, anyway.

It depends on how you set your focus policy for a window manager.
Both in Enlightment, which I use mostly, and in KDE, which I check
occasionally, I set a focus-follows-mouse policy in which I raise the
focused window.  For one, I personally cannot stand having a part of
my active window hidden.  You can do otherwise.  At least one other
person reports a preference for click-to-focus.  The two variations
are a user choice.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: mouse-autoselect-window

[Drew Adams]

>     >     Non-nil means autoselect window with mouse pointer.
>
>     If the window with the mouse pointer is in a different frame, then
>     that sentence ...
>
> The documentation (the sentence after the right angle) does not talk
> about frames at all.  So why would you expect a mouse pointer to focus
> another frame?

Windows are in frames. Selecting a window also selects its frame. A window's
frame is selected if the window is autoselected.

If the statement says nothing that restricts "window" to refer only to
windows on the same frame, then it purports to apply to any window, on any
frame.

Re: mouse-autoselect-window

[martin rudalics]

 > I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
 > click-to-focus policy but also have mouse-autoselect-window set to t,
 > because I want to have autoselection between split windows within a
 > single frame.  I also observe the same behavior that Drew Adams
 > described.

Seems like a bug, indeed.  Could you try the attached patch (against
Emacs_22_BASE) with `focus-follows-mouse' nil and
`mouse-autoselect-window' non-nil?  We'd also have to remove the

This variable does not have any effect on MS-Windows.

statement in the `focus-follows-mouse' doc-string (and as Drew suggested
update the documentation).


*** window.el.~1.120.2.2.~	Wed Aug  8 23:12:06 2007
--- window.el	Wed Sep  5 19:59:54 2007
***************
*** 853,858 ****
--- 853,863 ----
   	  ;; Delayed autoselection was temporarily suspended, reenable it.
   	  (mouse-autoselect-window-start mouse-position))
   	 ((and window (not (eq window (selected-window)))
+ 	       (or focus-follows-mouse
+ 		   ;; With `focus-follows-mouse' nil, do autoselection
+ 		   ;; if and only if we're within the same frame.
+ 		   (eq (window-frame window)
+ 		       (window-frame (selected-window))))
   	       (or (not (numberp mouse-autoselect-window))
   		   (and (> mouse-autoselect-window 0)
   			;; If `mouse-autoselect-window' is positive, select

RE: mouse-autoselect-window

[Drew Adams]

>  > I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
>  > click-to-focus policy but also have mouse-autoselect-window set to t,
>  > because I want to have autoselection between split windows within a
>  > single frame.  I also observe the same behavior that Drew Adams
>  > described.
>
> Seems like a bug, indeed.  Could you try the attached patch (against
> Emacs_22_BASE) with `focus-follows-mouse' nil and
> `mouse-autoselect-window' non-nil?  We'd also have to remove the
>
> This variable does not have any effect on MS-Windows.
>
> statement in the `focus-follows-mouse' doc-string (and as Drew suggested
> update the documentation).
>
> + 	       (or focus-follows-mouse
> + 		   ;; With `focus-follows-mouse' nil, do autoselection
> + 		   ;; if and only if we're within the same frame.
> + 		   (eq (window-frame window)
> + 		       (window-frame (selected-window))))

Not sure I understand.

1. That does not select a window in another frame if you move the mouse to
it, regardless of the setting of focus-follows-mouse (on MS Windows).

2. It doesn't change the behavior of window selection within the same frame
(on MS Windows). On MS Windows, focus-follows-mouse has no effect. (So that
sentence should also not be removed from the doc.)

I think your fix might be needed for GNU/Linux etc. - I don't know. Looking
at it, it makes sense. But it does not address any issues I raised, AFAICT.

BTW (did I mention this?) - the doc string for focus-follows-mouse should
say that it is about frames, not about focus in windows (which might be in
the same frame).

Re: mouse-autoselect-window

[martin rudalics]

 > Not sure I understand.
 >
 > 1. That does not select a window in another frame if you move the mouse to
 > it, regardless of the setting of focus-follows-mouse (on MS Windows).

It should when you set `focus-follows-mouse' to non-nil and you have
tweaked the registry of Windows appropriately.

 > 2. It doesn't change the behavior of window selection within the same frame
 > (on MS Windows).

Hopefully not!

 > On MS Windows, focus-follows-mouse has no effect. (So that
 > sentence should also not be removed from the doc.)

The sentence would have been wrong after the bug got fixed.  But Jason
removed it already.

 > I think your fix might be needed for GNU/Linux etc. - I don't know. Looking
 > at it, it makes sense. But it does not address any issues I raised, AFAICT.

Did you apply it?  If not, please do and try to reproduce your problem.

 > BTW (did I mention this?) - the doc string for focus-follows-mouse should
 > say that it is about frames, not about focus in windows (which might be in
 > the same frame).

The doc string doesn't talk about windows, it talks about window sytems
and window managers.  The crucial part of it is the second sentence:

     You should set this variable to tell Emacs how your window manager
     handles focus, since there is no way in general for Emacs to find out
     automatically.

RE: mouse-autoselect-window

[Drew Adams]

>  > Not sure I understand.
>  >
>  > 1. That does not select a window in another frame if you move
>  >    the mouse to it, regardless of the setting of
>  >    focus-follows-mouse (on MS Windows).
>
> It should when you set `focus-follows-mouse' to non-nil and you have
> tweaked the registry of Windows appropriately.

Ah, you didn't mention that. So that means that you need to do this for all
applications, not just Emacs? That's too bad.

>  > 2. It doesn't change the behavior of window selection within
>  >    the same frame (on MS Windows).
>
> Hopefully not!
>
>  > On MS Windows, focus-follows-mouse has no effect. (So that
>  > sentence should also not be removed from the doc.)
>
> The sentence would have been wrong after the bug got fixed.  But Jason
> removed it already.

See my reply to Jason.

>  > I think your fix might be needed for GNU/Linux etc. - I don't
>  > know. Looking at it, it makes sense. But it does not address
>  > any issues I raised, AFAICT.
>
> Did you apply it?  If not, please do and try to reproduce your problem.

Of course I did. However, I have not "tweaked the registry". As you didn't
mention the registry, I expected it to change the behavior for Emacs - and
only Emacs, with no registry hacking.

>  > BTW (did I mention this?) - the doc string for
>  > focus-follows-mouse should say that it is about frames, not about
>  > focus in windows (which might be in the same frame).
>
> The doc string doesn't talk about windows, it talks about window sytems
> and window managers.  The crucial part of it is the second sentence:
>
>      You should set this variable to tell Emacs how your window manager
>      handles focus, since there is no way in general for Emacs to find out
>      automatically.

I repeat that the doc string should mention that this option is about frame
focus. And it should say that (apparently) the (only?) effect is that it
makes the mouse follow the frame focus, by moving the mouse to whatever
frame has the focus. None of this is clear from the doc string.

Re: mouse-autoselect-window

[martin rudalics]

 > Of course I did. However, I have not "tweaked the registry". As you didn't
 > mention the registry, I expected it to change the behavior for Emacs - and
 > only Emacs, with no registry hacking.

The patch was intended for the untweaked behavior.  It should simply
restrict autoselection to remain within one and the same frame when you
set `focus-follows-mouse' to nil (if this is the desired behavior).

RE: mouse-autoselect-window

[Drew Adams]

>  > Of course I did. However, I have not "tweaked the registry".
>  > As you didn't mention the registry, I expected it to change
>  > the behavior for Emacs - and only Emacs, with no registry hacking.
>
> The patch was intended for the untweaked behavior.  It should simply
> restrict autoselection to remain within one and the same frame when you
> set `focus-follows-mouse' to nil (if this is the desired behavior).

Well, it doesn't - at least not in my Windows XP.

At least if "autoselection" includes the behavior I described originally:
activate the mode line and update the tool bar. IOW, if I move the mouse to
a window in another frame, the mode line of that window is activated, and
the toolbar reflects that window's mode. These are normally (but in this
case are faulty) indications that the window is selected.

I'm not sure where those mode-line and tool-bar changes occur. If I
debug-on-entry handle-select-window, then I never see those changes take
effect (even just hitting `c' upon debugger entry). But without debugging,
those changes (mode line, tool bar) always take effect, regardless of the
frame of the destination window.

As I mentioned originally, if the destination window is on a different
frame, then the mode line and tool bar indicate that the window is selected
(active), but it is not in fact selected, as evidenced, for example, by
(current-buffer). So, the window is not truly selected, but there are visual
indications that it is. That is what I described in my original report.

Also, if I move to a window that is one-window-p, then handle-select-window
never gets called. Otherwise it gets called. In both cases, the mode line
and the tool bar are updated. Only when the window is not one-window-p is it
actually selected (so that its buffer is the current buffer).

I am using mouse-autoselect-window = t.

Re: mouse-autoselect-window

[Jason Rumney]

Drew Adams wrote:
> I repeat that the doc string should mention that this option is about frame
> focus. And it should say that (apparently) the (only?) effect

Variables do not have effects!

The purpose of the variable is clearly stated in the doc string. Its
purpose is to tell code that wants to use the variable what the window
system's focus policy is.

RE: mouse-autoselect-window

[Drew Adams]

> > I repeat that the doc string should mention that this option is
> > about frame focus. And it should say that (apparently) the
> > (only?) effect is that it makes the mouse follow the frame
> > focus, by moving the mouse to whatever frame has the focus.
>
> Variables do not have effects!

Shouting doesn't make your point more convincing.

Changing the value of a variable can have an effect. Apparently, the only
effect of _setting this variable to non-nil_ is that that makes the mouse
follow the frame. (Is there another user-noticeable effect?)

> The purpose of the variable is clearly stated in the doc string. Its
> purpose is to tell code that wants to use the variable what the window
> system's focus policy is.

And what might the code do with that information? What is the
user-observable change in behavior due to a change in value of the variable?
That information is important to understanding what this variable is for.

Re: mouse-autoselect-window

[Stefan Monnier]

> Changing the value of a variable can have an effect. Apparently, the only
> effect of _setting this variable to non-nil_ is that that makes the mouse
> follow the frame. (Is there another user-noticeable effect?)

Another user-noticeable effect is to make mouse-autoselect-window apply only
to windows within the selected frame.  ;-)

> And what might the code do with that information? What is the
> user-observable change in behavior due to a change in value of the variable?
> That information is important to understanding what this variable is for.

Agreed.  It doesn't have to be explicit, but should list some ideas of how
it may affect Emacs's behavior.  The most important one is to change the way
Emacs tries to change the selected frame.


        Stefan

Re: mouse-autoselect-window

[Leo]

On 2007-09-07 01:02 +0100, Stefan Monnier wrote:
>> Changing the value of a variable can have an effect. Apparently, the only
>> effect of _setting this variable to non-nil_ is that that makes the mouse
>> follow the frame. (Is there another user-noticeable effect?)
>
> Another user-noticeable effect is to make mouse-autoselect-window apply only
> to windows within the selected frame.  ;-)

I was not able to use mouse-autoselect-window with emacs running in
XTerm. Ideas?

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: mouse-autoselect-window

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> I was not able to use mouse-autoselect-window with emacs running in
> XTerm. Ideas?

xterm-mouse-mode can only report button events.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: mouse-autoselect-window

[Stephen Berman]

On Wed, 05 Sep 2007 20:04:15 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
>> click-to-focus policy but also have mouse-autoselect-window set to t,
>> because I want to have autoselection between split windows within a
>> single frame.  I also observe the same behavior that Drew Adams
>> described.
>
> Seems like a bug, indeed.  Could you try the attached patch (against
> Emacs_22_BASE) with `focus-follows-mouse' nil and
> `mouse-autoselect-window' non-nil?

I don't have Emacs_22_BASE but the patch applied cleanly to window.el
in the released Emacs 22.1.  However, I see no difference to the
behavior without the patch: with mouse-autoselect-window set to t and
focus-follows-mouse set to nil, moving the mouse over a non-focussed
frame still changes the mode-line face and the tool bar of its
windows, just as in the focussed frame.

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

 > I don't have Emacs_22_BASE but the patch applied cleanly to window.el
 > in the released Emacs 22.1.  However, I see no difference to the
 > behavior without the patch: with mouse-autoselect-window set to t and
 > focus-follows-mouse set to nil, moving the mouse over a non-focussed
 > frame still changes the mode-line face and the tool bar of its
 > windows, just as in the focussed frame.

I don't know whether debugging this is feasible but could you try to, in
`mouse-autoselect-window-select', insert some simple messages around the
lines I added and see why they apparently return non-nil. In particular
(window-frame window) shouldn't eq (window-frame (selected-window)) for
different frames.  Otherwise, I'd have to reset my registry somehow to
get the "standard" click-to-focus behavior :-(.

Re: mouse-autoselect-window

[Stephen Berman]

On Thu, 06 Sep 2007 14:22:23 +0200 martin rudalics <rudalics@gmx.at> wrote:

> I don't know whether debugging this is feasible but could you try to, in
> `mouse-autoselect-window-select', insert some simple messages around the
> lines I added and see why they apparently return non-nil. In particular
> (window-frame window) shouldn't eq (window-frame (selected-window)) for
> different frames.  Otherwise, I'd have to reset my registry somehow to
> get the "standard" click-to-focus behavior :-(.

I inserted messages in a progn before and after the sexp (eq
(window-frame window) (window-frame (selected-window))), and also
before and after mouse-autoselect-window-timer is set in
mouse-autoselect-window-start.  But in all cases no message was
issued.  I even redumped emacs, but still nothing.  Do you have a
suggestion that you know will show a message?

One thing I notice with mouse-autoselect-window non-nil: if I set it
to a noticeable delay, still when I move the mouse to another frame
with split windows, and there onto a different window than was
previously selected, then the previously selected mode line
immediately displays the active face, and switches to inactive after
the delay.  In other words, something in the mouse autoselect code
seems to take effect immediately, ignoring the delay, as long as
mouse-autoselect-window is non-nil.

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

 > I inserted messages in a progn before and after the sexp (eq
 > (window-frame window) (window-frame (selected-window))), and also
 > before and after mouse-autoselect-window-timer is set in
 > mouse-autoselect-window-start.  But in all cases no message was
 > issued.  I even redumped emacs, but still nothing.  Do you have a
 > suggestion that you know will show a message?

It always did when I tested this.  But this has been throughly tested
only on Unix and Windows, never on GNU/Linux.  Could you try removing
the outer `condition-case' of `mouse-autoselect-window-select', I
suppose it triggers some error before getting there.

 > One thing I notice with mouse-autoselect-window non-nil: if I set it
 > to a noticeable delay, still when I move the mouse to another frame
 > with split windows, and there onto a different window than was
 > previously selected, then the previously selected mode line
 > immediately displays the active face, and switches to inactive after
 > the delay.  In other words, something in the mouse autoselect code
 > seems to take effect immediately, ignoring the delay, as long as
 > mouse-autoselect-window is non-nil.

If it's on a different frame it should be avoided by the code I sent
you.  Something must be bypassing it ...

Re: mouse-autoselect-window

[Stephen Berman]

On Thu, 06 Sep 2007 17:10:17 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> I inserted messages in a progn before and after the sexp (eq
>> (window-frame window) (window-frame (selected-window))), and also
>> before and after mouse-autoselect-window-timer is set in
>> mouse-autoselect-window-start.  But in all cases no message was
>> issued.  I even redumped emacs, but still nothing.  Do you have a
>> suggestion that you know will show a message?
>
> It always did when I tested this.  But this has been throughly tested
> only on Unix and Windows, never on GNU/Linux.  Could you try removing
> the outer `condition-case' of `mouse-autoselect-window-select', I
> suppose it triggers some error before getting there.

I commented out the condition-case and the corresponding error sexp,
re-byte-compiled, redumped.  Still no messages, and no errors.  And
still the same behavior:

>> One thing I notice with mouse-autoselect-window non-nil: if I set it
>> to a noticeable delay, still when I move the mouse to another frame
>> with split windows, and there onto a different window than was
>> previously selected, then the previously selected mode line
>> immediately displays the active face, and switches to inactive after
>> the delay.  In other words, something in the mouse autoselect code
>> seems to take effect immediately, ignoring the delay, as long as
>> mouse-autoselect-window is non-nil.
>
> If it's on a different frame it should be avoided by the code I sent
> you.  Something must be bypassing it ...

Is anyone else able to reproduce what I see on GNU/Linux?

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

> I commented out the condition-case and the corresponding error sexp,
> re-byte-compiled, redumped.  Still no messages, and no errors.  And
> still the same behavior:

Is `mouse-autoselect-window-select' called at all?

Re: mouse-autoselect-window

[Stephen Berman]

On Thu, 06 Sep 2007 19:31:09 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> I commented out the condition-case and the corresponding error sexp,
>> re-byte-compiled, redumped.  Still no messages, and no errors.  And
>> still the same behavior:
>
> Is `mouse-autoselect-window-select' called at all?

How can I determine that?  The first thing I did after applying your
patch was to instrument mouse-autoselect-window-select for edebug, but
when I moved the mouse between windows (and frames) after setting
mouse-autoselect-window to t, edebug never kicked in.  I also
instrumented mouse-autoselect-window-start but still no edebug.  Does
this mean those functions are not being called?  If so, how is
mouse-autoselect-window taking effect; if not, why isn't edebug
working?

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

 >>Is `mouse-autoselect-window-select' called at all?
 >
 >
 > How can I determine that?  The first thing I did after applying your
 > patch was to instrument mouse-autoselect-window-select for edebug, but
 > when I moved the mouse between windows (and frames) after setting
 > mouse-autoselect-window to t, edebug never kicked in.  I also
 > instrumented mouse-autoselect-window-start but still no edebug.  Does
 > this mean those functions are not being called?  If so, how is
 > mouse-autoselect-window taking effect; if not, why isn't edebug
 > working?

This would mean that `handle-select-window' gets it wrong.  Can you look
there, especially why `mouse-autoselect-window-start' is not called?

Re: mouse-autoselect-window

[Stephen Berman]

On Thu, 06 Sep 2007 22:46:00 +0200 martin rudalics <rudalics@gmx.at> wrote:

>>>Is `mouse-autoselect-window-select' called at all?
>>
>>
>> How can I determine that?  The first thing I did after applying your
>> patch was to instrument mouse-autoselect-window-select for edebug, but
>> when I moved the mouse between windows (and frames) after setting
>> mouse-autoselect-window to t, edebug never kicked in.  I also
>> instrumented mouse-autoselect-window-start but still no edebug.  Does
>> this mean those functions are not being called?  If so, how is
>> mouse-autoselect-window taking effect; if not, why isn't edebug
>> working?
>
> This would mean that `handle-select-window' gets it wrong.  Can you look
> there, especially why `mouse-autoselect-window-start' is not called?

The reason is that I had mouse-autoselect-window set to t, and
handle-select-window contains this code:

      (unless (and (numberp mouse-autoselect-window)
		   (not (zerop mouse-autoselect-window))
		   (not (eq mouse-autoselect-window-state 'select))
		   (progn
		     ;; Cancel any delayed autoselection.
		     (mouse-autoselect-window-cancel t)
		     ;; Start delayed autoselection from current mouse position
		     ;; and window.
		     (mouse-autoselect-window-start (mouse-position) window)
		     ;; Executing a command cancels delayed autoselection.
		     (add-hook
		      'pre-command-hook 'mouse-autoselect-window-cancel)))

So (numberp mouse-autoselect-window) => (numberp t) => nil and
mouse-autoselect-window-start is skipped over.  When I set
mouse-autoselect-window to a number, I can use edebug to step through
mouse-autoselect-window-select.  The results I have gotten so far are
puzzling.  Sometimes (mouse-position) evaluates to e.g. (#<frame
*scratch* 0x8656d88> 42 . 9) and then the variable `window' gets
let-bound to #<frame *scratch* 0x8656d88>.  But sometimes
(mouse-position) evaluates to e.g. (#<frame *scratch* 0x8656d88> nil)
and then `window' evaluates to nil.  I haven't been able to see when
or why this happens, but when it does, your code gets skipped over.
But even when `window' has a valid window value, I find that in edebug
(selected-window) evaluated to the same window, so again your code
gets skipped over.  But when I don't use edebug and move the mouse
over another frame, then (selected-window) is still the window in the
frame I moved off of.  I don't understand this discrepancy, and I
don't understand how (selected window) could change.

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

 > The reason is that I had mouse-autoselect-window set to t, and
 > handle-select-window contains this code:

The incorrect behavior you reported (a window getting its modeline
highlighted but not the focus) was with `mouse-autoselect-window' t
then?

 > So (numberp mouse-autoselect-window) => (numberp t) => nil and
 > mouse-autoselect-window-start is skipped over.  When I set
 > mouse-autoselect-window to a number, I can use edebug to step through
 > mouse-autoselect-window-select.  The results I have gotten so far are
 > puzzling.  Sometimes (mouse-position) evaluates to e.g. (#<frame
 > *scratch* 0x8656d88> 42 . 9) and then the variable `window' gets
 > let-bound to #<frame *scratch* 0x8656d88>.  But sometimes
 > (mouse-position) evaluates to e.g. (#<frame *scratch* 0x8656d88> nil)
 > and then `window' evaluates to nil.  I haven't been able to see when
 > or why this happens, but when it does, your code gets skipped over.

As long as `window' is nil autoselection should continue looping, hence
this should not cause any harm.  Autoselection should also continue
looping when the frame of `window' is not that of the selected window.

 > But even when `window' has a valid window value, I find that in edebug
 > (selected-window) evaluated to the same window, so again your code
 > gets skipped over.  But when I don't use edebug and move the mouse
 > over another frame, then (selected-window) is still the window in the
 > frame I moved off of.  I don't understand this discrepancy, and I
 > don't understand how (selected window) could change.

It's hardly possible to avoid a Heisenbug here, I soon gave up using
edebug for this.

RE: mouse-autoselect-window

[Drew Adams]

>  > The reason is that I had mouse-autoselect-window set to t, and
>  > handle-select-window contains this code:
>
> The incorrect behavior you reported (a window getting its modeline
> highlighted but not the focus) was with `mouse-autoselect-window' t
> then?

I reported that behavior. Both mode-line and tool-bar are updated, but the
window is not really focused (as shown, e.g. by (current-buffer). I believe
that Stephen confirmed this.

Yes, mouse-autoselect-window = t.

Re: mouse-autoselect-window

[Stephen Berman]

On Fri, 7 Sep 2007 00:33:59 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:

>>  > The reason is that I had mouse-autoselect-window set to t, and
>>  > handle-select-window contains this code:
>>
>> The incorrect behavior you reported (a window getting its modeline
>> highlighted but not the focus) was with `mouse-autoselect-window' t
>> then?
>
> I reported that behavior. Both mode-line and tool-bar are updated, but the
> window is not really focused (as shown, e.g. by (current-buffer). I believe
> that Stephen confirmed this.

Yes.

> Yes, mouse-autoselect-window = t.

But as I noted in my reply to Martin Rudalics, I also see the same
thing when mouse-autoselect-window is set to a numerical value.

Steve Berman

Re: mouse-autoselect-window

[Robert J. Chassell]

   ... as I noted in my reply to Martin Rudalics, I also see the same
   thing when mouse-autoselect-window is set to a numerical value.

The documentation for `mouse-autoselect-window' says that a 
numerical value is the same as t:

    Non-nil means autoselect window with mouse pointer

so the same should happen.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: mouse-autoselect-window

[martin rudalics]

> I reported that behavior. Both mode-line and tool-bar are updated, but the
> window is not really focused (as shown, e.g. by (current-buffer). I believe
> that Stephen confirmed this.
> 
> Yes, mouse-autoselect-window = t.

What happens when you set it to 0.1 ?

Re: mouse-autoselect-window

[Stephen Berman]

On Fri, 07 Sep 2007 08:51:59 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> The reason is that I had mouse-autoselect-window set to t, and
>> handle-select-window contains this code:
>
> The incorrect behavior you reported (a window getting its modeline
> highlighted but not the focus) was with `mouse-autoselect-window' t
> then?

When I first confirmed Drew Adams's report of this behavior, I had
mouse-autoselect-window set to t.  But I also see the same thing when
it is set to a numerical value.

>> So (numberp mouse-autoselect-window) => (numberp t) => nil and
>> mouse-autoselect-window-start is skipped over.  When I set
>> mouse-autoselect-window to a number, I can use edebug to step through
>> mouse-autoselect-window-select.  The results I have gotten so far are
>> puzzling.  Sometimes (mouse-position) evaluates to e.g. (#<frame
>> *scratch* 0x8656d88> 42 . 9) and then the variable `window' gets
>> let-bound to #<frame *scratch* 0x8656d88>.  But sometimes
>> (mouse-position) evaluates to e.g. (#<frame *scratch* 0x8656d88> nil)
>> and then `window' evaluates to nil.  I haven't been able to see when
>> or why this happens, but when it does, your code gets skipped over.
>
> As long as `window' is nil autoselection should continue looping, hence
> this should not cause any harm.  Autoselection should also continue
> looping when the frame of `window' is not that of the selected window.

I don't understand what you mean by "autoselection should continue
looping", nor what harm it doesn't cause.

>> But even when `window' has a valid window value, I find that in edebug
>> (selected-window) evaluated to the same window, so again your code
>> gets skipped over.  But when I don't use edebug and move the mouse
>> over another frame, then (selected-window) is still the window in the
>> frame I moved off of.  I don't understand this discrepancy, and I
>> don't understand how (selected window) could change.
>
> It's hardly possible to avoid a Heisenbug here, I soon gave up using
> edebug for this.

Too bad, I often find edebug really helpful.  Oh well, guess I just
have to dirty my hands more with the code :-)

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

 > I don't understand what you mean by "autoselection should continue
 > looping", nor what harm it doesn't cause.

When window is nil this should mean that the mouse-pointer was not
hovering over one of Emacs' windows.  In this case I continue
mouse-tracking until the mouse-pointer reenters a window (a similar
scenario applies when the mouse-pointer is over the scroll-bar).  In any
of these cases window selection shouldn't occur.

 > Too bad, I often find edebug really helpful.  Oh well, guess I just
 > have to dirty my hands more with the code :-)

What we have to find out is whether it stays within the
mouse-autoselect-window code and, for example, issues multiple calls of
`select-window' in `handle-select-window' (this would be a bug in the
implementation of `mouse-autoselect-window-state') or it already left
the mouse-autoselect-window code and `select-window' doesn't DTRT here.

Re: mouse-autoselect-window

[Stephen Berman]

On Fri, 07 Sep 2007 10:53:45 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> I don't understand what you mean by "autoselection should continue
>> looping", nor what harm it doesn't cause.
>
> When window is nil this should mean that the mouse-pointer was not
> hovering over one of Emacs' windows.  

When I have seen window being nil in edebug, the mouse-pointer was
hovering over an Emacs window, AFAICT.  Unfortunately, the nil value
is sporadic, I don't know how to induce it (when, as I believe was the
case, the mouse-pointer is over an Emacs window).

>                                       In this case I continue
> mouse-tracking until the mouse-pointer reenters a window (a similar
> scenario applies when the mouse-pointer is over the scroll-bar).  In any
> of these cases window selection shouldn't occur.

Perhaps the mouse-pointer was indeed over the scroll-bar, or maybe the
tool bar or menu bar, is it the same with these, too?  I will take
another look at this.

>> Too bad, I often find edebug really helpful.  Oh well, guess I just
>> have to dirty my hands more with the code :-)
>
> What we have to find out is whether it stays within the
> mouse-autoselect-window code and, for example, issues multiple calls of
> `select-window' in `handle-select-window' (this would be a bug in the
> implementation of `mouse-autoselect-window-state') or it already left
> the mouse-autoselect-window code and `select-window' doesn't DTRT here.

I will try to do this sometime today, time permitting.

Steve Berman  

Re: mouse-autoselect-window

[martin rudalics]

 > When I have seen window being nil in edebug, the mouse-pointer was
 > hovering over an Emacs window, AFAICT.  Unfortunately, the nil value
 > is sporadic, I don't know how to induce it (when, as I believe was the
 > case, the mouse-pointer is over an Emacs window).

The nil value comes from `mouse-position' and `window-at'.  Processing
these is not 100% reliable hence there's another condition-case around
them.  Hence it's not clear whether there really was no window or
`window-at' failed.

 >>                                      In this case I continue
 >>mouse-tracking until the mouse-pointer reenters a window (a similar
 >>scenario applies when the mouse-pointer is over the scroll-bar).  In any
 >>of these cases window selection shouldn't occur.
 >
 >
 > Perhaps the mouse-pointer was indeed over the scroll-bar, or maybe the
 > tool bar or menu bar, is it the same with these, too?  I will take
 > another look at this.

I didn't care about the tool bar, it might cause troubles.  The menu bar
should not be part of any window.  I only handle scroll bar and popped
up menus (which could shadow part of a window).

Re: mouse-autoselect-window

[Stefan Monnier]

>>> I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
>>> click-to-focus policy but also have mouse-autoselect-window set to t,
>>> because I want to have autoselection between split windows within a
>>> single frame.  I also observe the same behavior that Drew Adams
>>> described.
>> 
>> Seems like a bug, indeed.  Could you try the attached patch (against
>> Emacs_22_BASE) with `focus-follows-mouse' nil and
>> `mouse-autoselect-window' non-nil?

> I don't have Emacs_22_BASE but the patch applied cleanly to window.el
> in the released Emacs 22.1.  However, I see no difference to the
> behavior without the patch: with mouse-autoselect-window set to t and
> focus-follows-mouse set to nil, moving the mouse over a non-focussed
> frame still changes the mode-line face and the tool bar of its
> windows, just as in the focussed frame.

Have you recompiled the window.el file?
Have you re-dumped Emacs in the mean time?


        Stefan

Re: mouse-autoselect-window

[Stephen Berman]

On Thu, 06 Sep 2007 10:30:39 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> I don't have Emacs_22_BASE but the patch applied cleanly to window.el
>> in the released Emacs 22.1.  However, I see no difference to the
>> behavior without the patch: with mouse-autoselect-window set to t and
>> focus-follows-mouse set to nil, moving the mouse over a non-focussed
>> frame still changes the mode-line face and the tool bar of its
>> windows, just as in the focussed frame.
>
> Have you recompiled the window.el file?

Yes

> Have you re-dumped Emacs in the mean time?

Yes

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

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

> I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
> click-to-focus policy but also have mouse-autoselect-window set to t,
> because I want to have autoselection between split windows within a
> single frame.  I also observe the same behavior that Drew Adams
> described.

I'm afraid that autoselection between windows of the same frame only
is somewhat very difficult to achieve.  The attached patch should
correct the behavior observed by Drew though.  Could you please try?

[-- Attachment #2: window.el.patch --]
[-- Type: text/plain, Size: 922 bytes --]

*** window.el.~1.120.2.2.~	Wed Aug  8 23:12:06 2007
--- window.el	Tue Sep 18 08:54:28 2007
***************
*** 921,927 ****
  	(setq mouse-autoselect-window-state nil)
  	(when mouse-autoselect-window
  	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
! 	  (run-hooks 'mouse-leave-buffer-hook))
  	(select-window window)))))
  
  (define-key ctl-x-map "2" 'split-window-vertically)
--- 921,932 ----
  	(setq mouse-autoselect-window-state nil)
  	(when mouse-autoselect-window
  	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
! 	  (run-hooks 'mouse-leave-buffer-hook)
! 	  (unless focus-follows-mouse
! 	    ;; Make sure frame is raised when autoselecting window and
! 	    ;; we assume that the window manager does not autoraise the
! 	    ;; frame of window.
! 	    (raise-frame (window-frame window))))
  	(select-window window)))))
  
  (define-key ctl-x-map "2" 'split-window-vertically)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: mouse-autoselect-window

[Stephen Berman]

On Tue, 18 Sep 2007 09:02:50 +0200 martin rudalics <rudalics@gmx.at> wrote:

> I'm afraid that autoselection between windows of the same frame only
> is somewhat very difficult to achieve.  The attached patch should
> correct the behavior observed by Drew though.  Could you please try?

I applied the patch to window.el of the released Emacs 22.1, since I
don't have the EMACS_22_BASE source, byte-compiled the file and
redumped emacs.  

Now when I make mouse-autoselect-window t and focus-follows-mouse nil,
then moving the mouse from one frame to another raises the latter
without putting it in focus.  But in the newly raised frame the mode
line of the window the mouse is over still becomes active and the tool
bar still changes appropriately.  Do you consider this correct
behavior?

Moreover, when I make mouse-autoselect-window a number, the behavior
is strange and rather complicated: if the unfocussed frame does not
have split windows, then it does not get raised when the mouse is
moved over it; if it does have split windows, then moving the mouse
over it always raises it after the delay, but only if I alternate
between which of the split windows I first move the mouse over -- if I
try moving over the same window first as I did the previous time, it
mostly does not get raised, but sometimes does, suggesting a timing
issue.  And moving the mouse back from the unfocussed to the focussed
frame shows the same behavior with respect to raising (i.e., only if
it is split and with the same alternation and timing issues).  And as
above, the active mode line and the tool bar change regardless of
focus or raised-ness.

BTW, sorry I have followed up on testing your previous patch; I didn't
get any further using edebug and haven't had time to try to understand
how the code works.  But I'd be happy to try out any specific
instructions.

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

 > Now when I make mouse-autoselect-window t and focus-follows-mouse nil,
 > then moving the mouse from one frame to another raises the latter
 > without putting it in focus.

What happens if you additionally select the frame in
`handle-select-window'?  Like

	(when mouse-autoselect-window
	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
	  (run-hooks 'mouse-leave-buffer-hook)
	  (unless focus-follows-mouse
	    ;; Make sure frame is raised when autoselecting window and
	    ;; we assume that the window manager does not autoraise the
	    ;; frame of window.
	    (select-frame (window-frame window))
	    (raise-frame (window-frame window))))

 > But in the newly raised frame the mode
 > line of the window the mouse is over still becomes active and the tool
 > bar still changes appropriately.  Do you consider this correct
 > behavior?

No.

 > Moreover, when I make mouse-autoselect-window a number, the behavior
 > is strange and rather complicated: if the unfocussed frame does not
 > have split windows, then it does not get raised when the mouse is
 > moved over it; if it does have split windows, then moving the mouse
 > over it always raises it after the delay, but only if I alternate
 > between which of the split windows I first move the mouse over -- if I
 > try moving over the same window first as I did the previous time, it
 > mostly does not get raised, but sometimes does, suggesting a timing
 > issue.  And moving the mouse back from the unfocussed to the focussed
 > frame shows the same behavior with respect to raising (i.e., only if
 > it is split and with the same alternation and timing issues).  And as
 > above, the active mode line and the tool bar change regardless of
 > focus or raised-ness.

Before `handle-select-window' gets executed the event reader schedules a
`handle-switch-frame' event which selects that frame and the previously
selected window of that frame.  I'm not yet sure how to "handle" that :-(

Re: mouse-autoselect-window

[Stephen Berman]

On Tue, 18 Sep 2007 16:07:01 +0200 martin rudalics <rudalics@gmx.at> wrote:

> What happens if you additionally select the frame in
> `handle-select-window'?  Like
>
> 	(when mouse-autoselect-window
> 	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
> 	  (run-hooks 'mouse-leave-buffer-hook)
> 	  (unless focus-follows-mouse
> 	    ;; Make sure frame is raised when autoselecting window and
> 	    ;; we assume that the window manager does not autoraise the
> 	    ;; frame of window.
> 	    (select-frame (window-frame window))
> 	    (raise-frame (window-frame window))))

With this and with mouse-autoselect-window set to t, moving the mouse
to another Emacs frame of the same session immediately raises and
focusses it.  That is the same as when I set the KDE focus policy to
focus follows mouse -- but since I have the policy set to focus
follows click, I would not expect Emacs to behave differently.

With mouse-autoselect-window set to a number, the behavior is the same
as I described in my previous message, i.e., raising only with split
windows but only in alternation and not focussing.  In other words,
here select-frame has no effect.

Steve Berman

RE: mouse-autoselect-window

[Drew Adams]

> > I disagree.  I'm running Emacs on GNU/Linux under KDE, I have a
> > click-to-focus policy but also have mouse-autoselect-window set to t,
> > because I want to have autoselection between split windows within a
> > single frame.  I also observe the same behavior that Drew Adams
> > described.
>
> I'm afraid that autoselection between windows of the same frame only
> is somewhat very difficult to achieve.  The attached patch should
> correct the behavior observed by Drew though.  Could you please try?

Yes and no (for me, on Windows).

It raises the frame, but it does not give it the input focus. I had already
said (on 2007-09-05) that giving focus to the frame at the cost of raising
it was a possibility:

> BTW, `mouse-autoselect-window' _could_ select the mouse window in MS
> Windows, even on another frame, at the cost of also raising that frame -
> just add `select-frame-set-input-focus' to its code. However, I'm not sure
> that is a good idea.  I assume that on GNU/Linux etc. the focus moves but
> the window is not raised - that's the behavior I would prefer, anyway.

I mentioned `select-frame-set-input-focus', whereas you used `raise-frame'.
The effect wrt raising is the same, but your fix does not change the input
focus (for me, on Windows).

I personally think that it would be OK to raise the frame too, if focus
cannot be given to it otherwise, but what would really be desirable is to
give focus to the frame (and window) without raising it. I don't know if
that is always possible (e.g. on MS Windows), but when it is possible, it
is, I think, the appropriate behavior.

Ideally, with customizable options, users would be able to control,
separately, autofocus and autoraise.

I also see another problem with your fix (it might not be due to the fix
itself, however). It doesn't always seem to raise the right frame. I don't
know why. I don't know if others will see the same problem.

If I have a narrow frame on top of a wider frame that has two windows, top
and bottom, then moving the mouse from the bottom window to the top actually
raises the other (narrow) frame, instead of just giving the focus to the top
window.

If frame 2 is directly under frame 1, then moving the mouse from window B to
window A should focus window A, but instead it raises frame 2.

Frame 1:
.............
|           |
|       A   |
|___________|
|           |
|       B   |
|...........|

Frame 2:
.......
|     |
|     |
|     |
|     |
|     |
|.....|

The behavior is actually erratic - sometimes it raises frame 2, sometimes it
does not.

I'd suggest trying with `select-frame-set-input-focus' instead of
`raise-frame'. For me, that DTRT (except that it would be even better to be
able to focus frame input without necessarily also raising it).

Re: mouse-autoselect-window

[martin rudalics]

Thanks for the report !

 > It raises the frame, but it does not give it the input focus. I had already
 > said (on 2007-09-05) that giving focus to the frame at the cost of raising
 > it was a possibility:
 >
 >
 >>BTW, `mouse-autoselect-window' _could_ select the mouse window in MS
 >>Windows, even on another frame, at the cost of also raising that frame -
 >>just add `select-frame-set-input-focus' to its code. However, I'm not sure
 >>that is a good idea.  I assume that on GNU/Linux etc. the focus moves but
 >>the window is not raised - that's the behavior I would prefer, anyway.
 >
 >
 > I mentioned `select-frame-set-input-focus', whereas you used `raise-frame'.
 > The effect wrt raising is the same, but your fix does not change the input
 > focus (for me, on Windows).

You're right.  But I can't use `select-frame-set-input-focus' because it
might move the mouse pointer as well.  Could you try with the following
substitute?

	(when mouse-autoselect-window
	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
	  (run-hooks 'mouse-leave-buffer-hook)
	  (unless focus-follows-mouse
	    ;; Make sure frame is raised and selected when autoselecting
	    ;; window and we assume that the window manager does not
	    ;; autoraise the frame of window.
	    (select-frame frame)
	    (raise-frame frame)
	    ;; Ensure, if possible, that frame gets input focus.
	    (cond ((memq window-system '(x mac))
		   (x-focus-frame frame))
		  ((eq window-system 'w32)
		   (w32-focus-frame frame)))))

 > I personally think that it would be OK to raise the frame too, if focus
 > cannot be given to it otherwise, but what would really be desirable is to
 > give focus to the frame (and window) without raising it. I don't know if
 > that is always possible (e.g. on MS Windows), but when it is possible, it
 > is, I think, the appropriate behavior.

We could make raising optional, BTW.  You could check whether you like
it better by removing the `raise-frame' line above.

 > Ideally, with customizable options, users would be able to control,
 > separately, autofocus and autoraise.

Agreed.

 > I also see another problem with your fix (it might not be due to the fix
 > itself, however). It doesn't always seem to raise the right frame. I don't
 > know why. I don't know if others will see the same problem.
 >
 > If I have a narrow frame on top of a wider frame that has two windows, top
 > and bottom, then moving the mouse from the bottom window to the top actually
 > raises the other (narrow) frame, instead of just giving the focus to the top
 > window.
 >
 > If frame 2 is directly under frame 1, then moving the mouse from window B to
 > window A should focus window A, but instead it raises frame 2.
 >
 > Frame 1:
 > .............
 > |           |
 > |       A   |
 > |___________|
 > |           |
 > |       B   |
 > |...........|
 >
 > Frame 2:
 > .......
 > |     |
 > |     |
 > |     |
 > |     |
 > |     |
 > |.....|
 >
 > The behavior is actually erratic - sometimes it raises frame 2, sometimes it
 > does not.

With `mouse-autoselect-window' t or a number?

RE: mouse-autoselect-window

[Drew Adams]

>  > It raises the frame, but it does not give it the input focus.
>  > I had already said (on 2007-09-05) that giving focus to the
>  > frame at the cost of raising it was a possibility:
>  >
>  >
>  >>BTW, `mouse-autoselect-window' _could_ select the mouse window in MS
>  >>Windows, even on another frame, at the cost of also raising
>  >>that frame - just add `select-frame-set-input-focus' to its code.
>  >>However, I'm not sure that is a good idea.  I assume that on
>  >>GNU/Linux etc. the focus moves but the window is not raised -
>  >>that's the behavior I would prefer, anyway.
>  >
>  > I mentioned `select-frame-set-input-focus', whereas you used
>  > `raise-frame'. The effect wrt raising is the same, but your
>  > fix does not change the input focus (for me, on Windows).
>
> You're right.  But I can't use `select-frame-set-input-focus' because it
> might move the mouse pointer as well.

(I don't remember what the problem with that is.)

> Could you try with the following substitute?
>
> 	(when mouse-autoselect-window
> 	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
> 	  (run-hooks 'mouse-leave-buffer-hook)
> 	  (unless focus-follows-mouse
> 	    ;; Make sure frame is raised and selected when autoselecting
> 	    ;; window and we assume that the window manager does not
> 	    ;; autoraise the frame of window.
> 	    (select-frame frame)
> 	    (raise-frame frame)
> 	    ;; Ensure, if possible, that frame gets input focus.
> 	    (cond ((memq window-system '(x mac))
> 		   (x-focus-frame frame))
> 		  ((eq window-system 'w32)
> 		   (w32-focus-frame frame)))))

`frame' is unbound here. Let-bind it to (window-frame window), and it works:

(defun handle-select-window (event)
  "Handle select-window events."
  (interactive "e")
  (let ((window (posn-window (event-start event))))
    (when (and (window-live-p window)
	       ;; Don't switch if we're currently in the minibuffer.
	       ;; This tries to work around problems where the minibuffer gets
	       ;; unselected unexpectedly, and where you then have to move
	       ;; your mouse all the way down to the minibuffer to select it.
	       (not (window-minibuffer-p (selected-window)))
	       ;; Don't switch to a minibuffer window unless it's active.
	       (or (not (window-minibuffer-p window))
		   (minibuffer-window-active-p window)))
      (unless (and (numberp mouse-autoselect-window)
		   (not (zerop mouse-autoselect-window))
		   (not (eq mouse-autoselect-window-state 'select))
		   (progn
		     ;; Cancel any delayed autoselection.
		     (mouse-autoselect-window-cancel t)
		     ;; Start delayed autoselection from current mouse position
		     ;; and window.
		     (mouse-autoselect-window-start (mouse-position) window)
		     ;; Executing a command cancels delayed autoselection.
		     (add-hook
		      'pre-command-hook 'mouse-autoselect-window-cancel)))
	;; Reset state of delayed autoselection.
	(setq mouse-autoselect-window-state nil)
	(when mouse-autoselect-window
	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
	  (run-hooks 'mouse-leave-buffer-hook)
          (unless focus-follows-mouse
 	    ;; Make sure frame is raised when autoselecting window and
 	    ;; we assume that the window manager does not autoraise the
 	    ;; frame of window.
            (let ((frame (window-frame window)))
              (select-frame frame)
              (raise-frame frame)
              ;; Ensure, if possible, that frame gets input focus.
              (cond ((memq window-system '(x mac))
                     (x-focus-frame frame))
                    ((eq window-system 'w32)
                     (w32-focus-frame frame))))))
	(select-window window)))))

This is an improvement, for me, but, as I said, it would be better if the
focus could be changed without necessarily raising the frame also. Those
should be two separate choices: focus & raise.

>  > I personally think that it would be OK to raise the frame too, if focus
>  > cannot be given to it otherwise, but what would really be
>  > desirable is to give focus to the frame (and window) without raising
>  > it. I don't know if that is always possible (e.g. on MS Windows), but
>  > when it is possible, it is, I think, the appropriate behavior.
>
> We could make raising optional, BTW.  You could check whether you like
> it better by removing the `raise-frame' line above.

That seems to have no effect - the frame is raised even without the call to
`raise-frame'. I presume that is because `w32-focus-frame', as its doc
string says, gives "FRAME input focus, raising to foreground if necessary".
Perhaps there is no way around this raising on Windows? Does someone know?

Again, to me, this is an improvement, even if the frame does get raised, but
if we could prevent raising (unless the user asks for that), that would be
better.

>  > Ideally, with customizable options, users would be able to control,
>  > separately, autofocus and autoraise.
>
> Agreed.
>
>  > I also see another problem with your fix (it might not be due
>  > to the fix itself, however). It doesn't always seem to raise
>  > the right frame. I don't know why. I don't know if others will
>  > see the same problem.
>
> With `mouse-autoselect-window' t or a number?

With `t'. Anyway, the code above does not seem to have this problem.

Re: mouse-autoselect-window

[martin rudalics]

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

 >>You're right.  But I can't use `select-frame-set-input-focus' because it
 >>might move the mouse pointer as well.
 >
 >
 > (I don't remember what the problem with that is.)

It's unrelated so we can use `select-frame-set-input-focus' here.

 > `frame' is unbound here. Let-bind it to (window-frame window), and it works:

Yes.

 > This is an improvement, for me, but, as I said, it would be better if the
 > focus could be changed without necessarily raising the frame also. Those
 > should be two separate choices: focus & raise.

I suppose we can do that by using either `my_set_focus' or
`my_set_foreground_window'.  I'll try to come up with a solution.

 > That seems to have no effect - the frame is raised even without the call to
 > `raise-frame'. I presume that is because `w32-focus-frame', as its doc
 > string says, gives "FRAME input focus, raising to foreground if necessary".
 > Perhaps there is no way around this raising on Windows? Does someone know?
 >
 > Again, to me, this is an improvement, even if the frame does get raised, but
 > if we could prevent raising (unless the user asks for that), that would be
 > better.

I agree.  I haven't tested this with multiple frames because I hardly
ever use them.

Stephen could you try the attached patch on GNU/Linux ?

[-- Attachment #2: window-el.patch --]
[-- Type: text/plain, Size: 937 bytes --]

*** window.el.~1.120.2.2.~	Wed Aug  8 23:12:06 2007
--- window.el	Tue Sep 18 18:45:20 2007
***************
*** 921,927 ****
  	(setq mouse-autoselect-window-state nil)
  	(when mouse-autoselect-window
  	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
! 	  (run-hooks 'mouse-leave-buffer-hook))
  	(select-window window)))))
  
  (define-key ctl-x-map "2" 'split-window-vertically)
--- 921,932 ----
  	(setq mouse-autoselect-window-state nil)
  	(when mouse-autoselect-window
  	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
! 	  (run-hooks 'mouse-leave-buffer-hook)
! 	  (unless focus-follows-mouse
! 	    ;; Make sure frame is focussed when autoselecting window and
! 	    ;; we assume that the window manager does not focus the
! 	    ;; frame of window.
! 	    (select-frame-set-input-focus (window-frame window))))
  	(select-window window)))))
  
  (define-key ctl-x-map "2" 'split-window-vertically)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: mouse-autoselect-window

[Drew Adams]

>  > This is an improvement, for me, but, as I said, it would be 
>  > better if the focus could be changed without necessarily
>  > raising the frame also. Those should be two separate choices:
>  > focus & raise.
> 
> I suppose we can do that by using either `my_set_focus' or
> `my_set_foreground_window'.  I'll try to come up with a solution.

Thanks.

Re: mouse-autoselect-window

[Stephen Berman]

On Tue, 18 Sep 2007 18:47:03 +0200 martin rudalics <rudalics@gmx.at> wrote:

> Stephen could you try the attached patch on GNU/Linux ?

With this and with mouse-autoselect-window set to t, moving the mouse
to another Emacs frame of the same session immediately raises and
focusses it, just like with your other patch using select-frame and
raise-frame.  Again, that is the same as when I set the KDE focus
policy to focus follows mouse -- but again, since I have the policy
set to focus follows click, I would not expect Emacs to behave
differently.

With mouse-autoselect-window set to a number, I get both raising and
focussing, but only with split windows and only in alternation.  As
before, with unsplit frame moving the mouse over another frame neither
raises nor focusses.

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

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

 > With this and with mouse-autoselect-window set to t, moving the mouse
 > to another Emacs frame of the same session immediately raises and
 > focusses it, just like with your other patch using select-frame and
 > raise-frame.  Again, that is the same as when I set the KDE focus
 > policy to focus follows mouse -- but again, since I have the policy
 > set to focus follows click, I would not expect Emacs to behave
 > differently.
 >
 > With mouse-autoselect-window set to a number, I get both raising and
 > focussing, but only with split windows and only in alternation.  As
 > before, with unsplit frame moving the mouse over another frame neither
 > raises nor focusses.

I tried to fix a couple of bugs.  Could you please try again with the
attached patches (against CVS EMACS_22_BASE) and all settings you can
reasonably test.

[-- Attachment #2: mouse-autoselect-src.patch --]
[-- Type: text/plain, Size: 5047 bytes --]

*** frame.c	Wed Jul 25 07:15:52 2007
--- frame.c	Fri Sep 28 10:39:16 2007
***************
*** 118,123 ****
--- 118,125 ----
  Lisp_Object Vmouse_position_function;
  Lisp_Object Vmouse_highlight;
  Lisp_Object Vdelete_frame_functions;
+ 
+ int focus_follows_mouse;
  \f
  static void
  set_menu_bar_lines_1 (window, n)
***************
*** 4151,4156 ****
--- 4153,4173 ----
  
  This variable is local to the current terminal and cannot be buffer-local.  */);
  
+   DEFVAR_BOOL ("focus-follows-mouse", &focus_follows_mouse,
+ 	       doc: /* Non-nil if window system changes focus when you move the mouse.
+ You should set this variable to tell Emacs how your window manager
+ handles focus, since there is no way in general for Emacs to find out
+ automatically.   */);
+ #ifdef HAVE_WINDOW_SYSTEM
+ #if defined(HAVE_NTGUI) || defined(MAC_OS)
+   focus_follows_mouse = 0;
+ #else
+   focus_follows_mouse = 1;
+ #endif
+ #else
+   focus_follows_mouse = 0;
+ #endif
+ 	 
    staticpro (&Vframe_list);
  
    defsubr (&Sactive_minibuffer_window);

*** frame.h	Fri Sep 14 22:50:14 2007
--- frame.h	Fri Sep 28 10:40:38 2007
***************
*** 39,44 ****
--- 39,49 ----
  
  extern int message_buf_print;
  
+ /* Nonzero means window system changes focus when moving the
+    mouse.  */
+ 
+ extern int focus_follows_mouse;
+ 
  \f
  /* The structure representing a frame.  */
  

*** keyboard.c	Fri Sep 14 22:50:16 2007
--- keyboard.c	Fri Sep 28 10:42:30 2007
***************
*** 3995,4000 ****
--- 3995,4003 ----
    /* Wait until there is input available.  */
    for (;;)
      {
+       if (CONSP (Vunread_command_events))
+ 	break;
+       
        if (kbd_fetch_ptr != kbd_store_ptr)
  	break;
  #ifdef HAVE_MOUSE

*** macterm.c	Tue Aug 28 08:27:32 2007
--- macterm.c	Fri Sep 28 10:43:52 2007
***************
*** 11119,11125 ****
  			     will be selected only when it is active.  */
  			  if (WINDOWP (window)
  			      && !EQ (window, last_window)
! 			      && !EQ (window, selected_window))
  			    {
  			      inev.kind = SELECT_WINDOW_EVENT;
  			      inev.frame_or_window = window;
--- 11119,11128 ----
  			     will be selected only when it is active.  */
  			  if (WINDOWP (window)
  			      && !EQ (window, last_window)
! 			      && !EQ (window, selected_window)
! 			      && (focus_follows_mouse
! 				  || (EQ (XWINDOW (window)->frame,
! 					  XWINDOW (selected_window)->frame))))
  			    {
  			      inev.kind = SELECT_WINDOW_EVENT;
  			      inev.frame_or_window = window;

*** msdos.c	Wed Aug  8 23:12:16 2007
--- msdos.c	Fri Sep 28 10:46:08 2007
***************
*** 3393,3399 ****
  		 it is active.  */
  	      if (WINDOWP (mouse_window)
  		  && !EQ (mouse_window, last_mouse_window)
! 		  && !EQ (mouse_window, selected_window))
  		{
  		  event.kind = SELECT_WINDOW_EVENT;
  		  event.frame_or_window = mouse_window;
--- 3393,3402 ----
  		 it is active.  */
  	      if (WINDOWP (mouse_window)
  		  && !EQ (mouse_window, last_mouse_window)
! 		  && !EQ (window, selected_window)
! 		  && (focus_follows_mouse
! 		      || (EQ (XWINDOW (window)->frame,
! 			      XWINDOW (selected_window)->frame))))
  		{
  		  event.kind = SELECT_WINDOW_EVENT;
  		  event.frame_or_window = mouse_window;

*** w32term.c	Sat Sep 22 10:39:36 2007
--- w32term.c	Fri Sep 28 10:44:58 2007
***************
*** 4339,4345 ****
  		     only when it is active.  */
  		  if (WINDOWP(window)
  		      && !EQ (window, last_window)
! 		      && !EQ (window, selected_window))
  		    {
  		      inev.kind = SELECT_WINDOW_EVENT;
  		      inev.frame_or_window = window;
--- 4339,4348 ----
  		     only when it is active.  */
  		  if (WINDOWP(window)
  		      && !EQ (window, last_window)
! 		      && !EQ (window, selected_window)
! 		      && (focus_follows_mouse
! 			  || (EQ (XWINDOW (window)->frame,
! 				  XWINDOW (selected_window)->frame))))
  		    {
  		      inev.kind = SELECT_WINDOW_EVENT;
  		      inev.frame_or_window = window;

*** xterm.c	Fri Sep 14 22:50:16 2007
--- xterm.c	Fri Sep 28 10:45:24 2007
***************
*** 6628,6634 ****
                     will be selected only when it is active.  */
                  if (WINDOWP (window)
                      && !EQ (window, last_window)
!                     && !EQ (window, selected_window))
                    {
                      inev.ie.kind = SELECT_WINDOW_EVENT;
                      inev.ie.frame_or_window = window;
--- 6628,6637 ----
                     will be selected only when it is active.  */
                  if (WINDOWP (window)
                      && !EQ (window, last_window)
! 		    && !EQ (window, selected_window)
! 		    && (focus_follows_mouse
! 			|| (EQ (XWINDOW (window)->frame,
! 				XWINDOW (selected_window)->frame))))
                    {
                      inev.ie.kind = SELECT_WINDOW_EVENT;
                      inev.ie.frame_or_window = window;


[-- Attachment #3: mouse-autoselect-lisp.patch --]
[-- Type: text/plain, Size: 5781 bytes --]

*** cus-start.el	Wed Jul 25 06:47:32 2007
--- cus-start.el	Fri Sep 28 10:48:14 2007
***************
*** 167,172 ****
--- 167,173 ----
  	     ;; fns.c
  	     (use-dialog-box menu boolean "21.1")
  	     (use-file-dialog menu boolean "22.1")
+ 	     (focus-follows-mouse frames boolean "20.3")
  	     ;; frame.c
  	     (default-frame-alist frames
  	       (repeat (cons :format "%v"

*** frame.el	Fri Sep 28 10:33:36 2007
--- frame.el	Fri Sep 28 10:49:38 2007
***************
*** 681,695 ****
  	(nreverse frame-initial-geometry-arguments))
    (cdr param-list))
  
- (defcustom focus-follows-mouse (not (memq window-system '(mac w32)))
-   "*Non-nil if window system changes focus when you move the mouse.
- You should set this variable to tell Emacs how your window manager
- handles focus, since there is no way in general for Emacs to find out
- automatically."
-   :type 'boolean
-   :group 'frames
-   :version "20.3")
- 
  (defun select-frame-set-input-focus (frame)
    "Select FRAME, raise it, and set input focus, if possible."
      (select-frame frame)
--- 681,686 ----

*** window.el	Wed Aug  8 23:12:06 2007
--- window.el	Fri Sep 28 10:53:36 2007
***************
*** 805,814 ****
    "Cancel delayed window autoselection.
  Optional argument FORCE means cancel unconditionally."
    (unless (and (not force)
! 	       ;; Don't cancel while the user drags a scroll bar.
! 	       (eq this-command 'scroll-bar-toolkit-scroll)
! 	       (memq (nth 4 (event-end last-input-event))
! 		     '(handle end-scroll)))
      (setq mouse-autoselect-window-state nil)
      (when (timerp mouse-autoselect-window-timer)
        (cancel-timer mouse-autoselect-window-timer))
--- 805,817 ----
    "Cancel delayed window autoselection.
  Optional argument FORCE means cancel unconditionally."
    (unless (and (not force)
! 	       ;; Don't cancel for select-window or select-frame events
! 	       ;; or when the user drags a scroll bar.
! 	       (or (memq this-command
! 			 '(handle-select-window handle-switch-frame))
! 		   (and (eq this-command 'scroll-bar-toolkit-scroll)
! 			(memq (nth 4 (event-end last-input-event))
! 			      '(handle end-scroll)))))
      (setq mouse-autoselect-window-state nil)
      (when (timerp mouse-autoselect-window-timer)
        (cancel-timer mouse-autoselect-window-timer))
***************
*** 896,928 ****
    "Handle select-window events."
    (interactive "e")
    (let ((window (posn-window (event-start event))))
!     (when (and (window-live-p window)
! 	       ;; Don't switch if we're currently in the minibuffer.
! 	       ;; This tries to work around problems where the minibuffer gets
! 	       ;; unselected unexpectedly, and where you then have to move
! 	       ;; your mouse all the way down to the minibuffer to select it.
! 	       (not (window-minibuffer-p (selected-window)))
! 	       ;; Don't switch to a minibuffer window unless it's active.
! 	       (or (not (window-minibuffer-p window))
! 		   (minibuffer-window-active-p window)))
!       (unless (and (numberp mouse-autoselect-window)
! 		   (not (zerop mouse-autoselect-window))
! 		   (not (eq mouse-autoselect-window-state 'select))
! 		   (progn
! 		     ;; Cancel any delayed autoselection.
! 		     (mouse-autoselect-window-cancel t)
! 		     ;; Start delayed autoselection from current mouse position
! 		     ;; and window.
! 		     (mouse-autoselect-window-start (mouse-position) window)
! 		     ;; Executing a command cancels delayed autoselection.
! 		     (add-hook
! 		      'pre-command-hook 'mouse-autoselect-window-cancel)))
  	;; Reset state of delayed autoselection.
  	(setq mouse-autoselect-window-state nil)
! 	(when mouse-autoselect-window
! 	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
! 	  (run-hooks 'mouse-leave-buffer-hook))
! 	(select-window window)))))
  
  (define-key ctl-x-map "2" 'split-window-vertically)
  (define-key ctl-x-map "3" 'split-window-horizontally)
--- 899,937 ----
    "Handle select-window events."
    (interactive "e")
    (let ((window (posn-window (event-start event))))
!     (unless (or (not (window-live-p window))
! 		;; Don't switch if we're currently in the minibuffer.
! 		;; This tries to work around problems where the
! 		;; minibuffer gets unselected unexpectedly, and where
! 		;; you then have to move your mouse all the way down to
! 		;; the minibuffer to select it.
! 		(window-minibuffer-p (selected-window))
! 		;; Don't switch to minibuffer window unless it's active.
! 		(and (window-minibuffer-p window)
! 		     (not (minibuffer-window-active-p window)))
! 		;; Don't switch when autoselection shall be delayed.
! 		(and (numberp mouse-autoselect-window)
! 		     (not (zerop mouse-autoselect-window))
! 		     (not (eq mouse-autoselect-window-state 'select))
! 		     (progn
! 		       ;; Cancel any delayed autoselection.
! 		       (mouse-autoselect-window-cancel t)
! 		       ;; Start delayed autoselection from current mouse position
! 		       ;; and window.
! 		       (mouse-autoselect-window-start (mouse-position) window)
! 		       ;; Executing a command cancels delayed autoselection.
! 		       (add-hook
! 			'pre-command-hook 'mouse-autoselect-window-cancel))))
!       (when mouse-autoselect-window
  	;; Reset state of delayed autoselection.
  	(setq mouse-autoselect-window-state nil)
! 	;; Set input focus to handle cross-frame movement.  Bind
! 	;; `focus-follows-mouse' to avoid moving the mouse cursor.
! 	(let (focus-follows-mouse)
! 	  (select-frame-set-input-focus (window-frame window)))
! 	;; Run `mouse-leave-buffer-hook' when autoselecting window.
! 	(run-hooks 'mouse-leave-buffer-hook))
!       (select-window window))))
  
  (define-key ctl-x-map "2" 'split-window-vertically)
  (define-key ctl-x-map "3" 'split-window-horizontally)


[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: mouse-autoselect-window

[Glenn Morris]

martin rudalics wrote:

> I tried to fix a couple of bugs.  Could you please try again with the
> attached patches (against CVS EMACS_22_BASE) and all settings you can
> reasonably test.

I it tried under Gnome and Window Maker, with and without focus
follows mouse in the window manager, with f-f-m nil and t, and m-a-w
nil, t, and 0.1. Results:

                      f-f-m
m-a-w           nil         t
nil             ok          ok
t               ok           1
0.1             ok           2


1) Works fine with focus follows mouse in the window manager. With a
click-to-focus window manager, then moving to another frame selects it.

2) Works fine with focus follows mouse in the window manager. With a
click-to-focus window manager, then moving to another frame exhibits
the old erroneous behaviour: the mode-line changes to active, but the
frame is not selected.

It could well be argued that these two cases are not important,
because focus-follows-mouse has the wrong setting (does not match the
window manager policy).

HTH.

Re: mouse-autoselect-window

[martin rudalics]

 > I it tried under Gnome and Window Maker, with and without focus
 > follows mouse in the window manager, with f-f-m nil and t, and m-a-w
 > nil, t, and 0.1. Results:
 >
 >                       f-f-m
 > m-a-w           nil         t
 > nil             ok          ok
 > t               ok           1
 > 0.1             ok           2
 >
 >
 > 1) Works fine with focus follows mouse in the window manager. With a
 > click-to-focus window manager, then moving to another frame selects it.

That's the inherent deficiency of Emacs generating a switch-frame event
when there's a SELECT_WINDOW_EVENT.  Whatever I do to ignore the latter
the former still gets in the way.  It was also the reason for moving
`focus-follows-mouse' to C level.  Now I can blame the user for not
setting this correctly - I'll have to state that in the doc-string of
`focus-follows-mouse', obviously.

 > 2) Works fine with focus follows mouse in the window manager. With a
 > click-to-focus window manager, then moving to another frame exhibits
 > the old erroneous behaviour: the mode-line changes to active, but the
 > frame is not selected.

The same.  For an integer (positive or negative) I have to schedule a
SELECT_WINDOW_EVENT because I must assume that the window-manager
supports a focus follows mouse policy.

 > It could well be argued that these two cases are not important,
 > because focus-follows-mouse has the wrong setting (does not match the
 > window manager policy).

That was the driving idea.  Alternatively I would have had to introduce
another variable like `mouse-autoselect-frame'.

 > HTH.

Yes, it's the expected behavior.  Could you, with m-a-w 1.0 and f-f-m t
and focus follows mouse in the window manager confirm that the following
DTRT: You have two frames A and B.  A has two windows 1 and 2, where 1
is active and has the mouse cursor in it.  Move the mouse to frame B to
select it.  Now move the mouse to window 2 on frame A.  Does it get
selected?  Before, Emacs consumed 99% CPU here because it got trapped in
the for (;;) loop of kbd_buffer_get_event with an unread select-window
event (you should be able to reproduce this with the scenario above and
without my patch applied).

Another issue is whether Emacs should be able to focus a frame but _not_
raise it simultaneously.  I use auto-raise window-management.  Hence,
Emacs policy and that of my window manager coincide.  AFAIK, many focus
follows mouse users prefer a focus-only policy which clashes with the
current behavior.  Fixing this is beyond Emacs 22, though.  Moreover,
we'd have to decide first how a switch-frame event issued by a
focus-only window-manager could inhibit Emacs raising the frame.

Thanks a lot for testing.

Re: mouse-autoselect-window

[Glenn Morris]

martin rudalics wrote:

> Could you, with m-a-w 1.0 and f-f-m t and focus follows mouse in the
> window manager confirm that the following DTRT: You have two frames
> A and B. A has two windows 1 and 2, where 1 is active and has the
> mouse cursor in it. Move the mouse to frame B to select it. Now move
> the mouse to window 2 on frame A. Does it get selected?

Yes.

>  Before, Emacs consumed 99% CPU here because it got trapped in the
> for (;;) loop of kbd_buffer_get_event with an unread select-window
> event (you should be able to reproduce this with the scenario above
> and without my patch applied).

Yes, I could reproduce that (but not 100% of the time).

Re: mouse-autoselect-window

[martin rudalics]

>>Could you, with m-a-w 1.0 and f-f-m t and focus follows mouse in the
>>window manager confirm that the following DTRT: You have two frames
>>A and B. A has two windows 1 and 2, where 1 is active and has the
>>mouse cursor in it. Move the mouse to frame B to select it. Now move
>>the mouse to window 2 on frame A. Does it get selected?
> 
> 
> Yes.
> 
> 
>> Before, Emacs consumed 99% CPU here because it got trapped in the
>>for (;;) loop of kbd_buffer_get_event with an unread select-window
>>event (you should be able to reproduce this with the scenario above
>>and without my patch applied).
> 
> 
> Yes, I could reproduce that (but not 100% of the time).

If there are no complaints I put this in Emacs_22_Base in 5 days.

Re: mouse-autoselect-window

[Stephen Berman]

On Fri, 28 Sep 2007 11:11:00 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> With this and with mouse-autoselect-window set to t, moving the mouse
>> to another Emacs frame of the same session immediately raises and
>> focusses it, just like with your other patch using select-frame and
>> raise-frame.  Again, that is the same as when I set the KDE focus
>> policy to focus follows mouse -- but again, since I have the policy
>> set to focus follows click, I would not expect Emacs to behave
>> differently.
>>
>> With mouse-autoselect-window set to a number, I get both raising and
>> focussing, but only with split windows and only in alternation.  As
>> before, with unsplit frame moving the mouse over another frame neither
>> raises nor focusses.
>
> I tried to fix a couple of bugs.  Could you please try again with the
> attached patches (against CVS EMACS_22_BASE) and all settings you can
> reasonably test.

I'm sorry I never responded to your request; I was travelling when it
arrived, then sick, then too busy to test it carefully.  In the mean
time, I see a corrected version is installed in the trunk.  I just
wanted to confirm that this version does what I expect: with my mouse
follows click policy, focus-follows-mouse set to nil and
mouse-autoselect-window set to non-nil, moving the mouse over a
non-selected frame no longer makes the mode line of that frame active,
nor changes the tool bar or frame title, also in the split-window
cases.  Thanks (belatedly) for fixing this issue.

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

> ... I just
> wanted to confirm that this version does what I expect: with my mouse
> follows click policy, focus-follows-mouse set to nil and
> mouse-autoselect-window set to non-nil, moving the mouse over a
> non-selected frame no longer makes the mode line of that frame active,
> nor changes the tool bar or frame title, also in the split-window
> cases.  Thanks (belatedly) for fixing this issue.

Thanks for testing.  I'm afraid that your problem was the only one I
was able to fix.  Moving from one frame to another still doesn't seem
to DTRT with focus-follows-mouse t.

Re: mouse-autoselect-window

[Stephen Berman]

On Wed, 07 Nov 2007 14:13:43 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> ... I just
>> wanted to confirm that this version does what I expect: with my mouse
>> follows click policy, focus-follows-mouse set to nil and
>> mouse-autoselect-window set to non-nil, moving the mouse over a
>> non-selected frame no longer makes the mode line of that frame active,
>> nor changes the tool bar or frame title, also in the split-window
>> cases.  Thanks (belatedly) for fixing this issue.
>
> Thanks for testing.  I'm afraid that your problem was the only one I
> was able to fix.  Moving from one frame to another still doesn't seem
> to DTRT with focus-follows-mouse t.

I do see that with a focus follows click policy, focus-follows-mouse set
to t and mouse-autoselect-window set to non-nil, then my problem
returns, but that would be my fault for making Emacs flout the window
manager policy.  If I use a focus follows mouse policy, I don't see any
problem with focus-follows-mouse set to t and mouse-autoselect-window
set to non-nil.  I recall there was an issue with auto-raising, but I
guess you dealt with that, because I don't see it in the preceding
scenario (using a non-auto-raising policy in the window manager).

Steve Berman

Re: mouse-autoselect-window

[martin rudalics]

> ... If I use a focus follows mouse policy, I don't see any
> problem with focus-follows-mouse set to t and mouse-autoselect-window
> set to non-nil.  ...

You would have to test that for some time at least.  Occasionally,
a frame gets selected but doesn't get focus.  Maybe on my system only.

Re: mouse-autoselect-window

[Jason Rumney]

martin rudalics wrote:
>         (cond ((memq window-system '(x mac))
>            (x-focus-frame frame))
>           ((eq window-system 'w32)
>            (w32-focus-frame frame)))))

If I understand correctly, you've dropped this in your latest iteration,
but I just renamed w32-focus-frame to x-focus-frame, as it breaks the
policy to keep the same name when the interfaces don't change between
platforms, and thus unnecessarily complicates code like the above.

I noticed as I was changing this, that there are two occurrences of the
above cond in frame.el. The first appears to have mac misspelt as max (I
thought at the time that it might mean the X API on Mac, which Emacs
used to work with before the Carbon port IIRC), the second is missing it
completely. Should they both be as above?

RE: mouse-autoselect-window

[Drew Adams]

> I just renamed w32-focus-frame to x-focus-frame, as it breaks the
> policy to keep the same name when the interfaces don't change between
> platforms, and thus unnecessarily complicates code like the above.

Shouldn't it be renamed to `focus-frame'? Don't we usually drop the `x-' for
the generic name, as in `color-defined-p' vs `x-color-defined-p'?

I see, however, that there was previously a function `focus-frame', and it
is now declared obsolete. This could invite confusion, I'm afraid, now
matter how we choose the name, as long as it contains "focus-frame". Oh
well...

BTW, where is x-focus-frame defined? I don't see it in frame.el or frame.c.
(I can see w32-focus-frame defined in w32fns.c.)

Re: mouse-autoselect-window

[Jason Rumney]

Drew Adams wrote:
> Shouldn't it be renamed to `focus-frame'? Don't we usually drop the `x-' for
> the generic name, as in `color-defined-p' vs `x-color-defined-p'?
>   

I think the latter was changed when support for colors on a tty was
added. There are many functions in the w32 and mac code prefixed with x-.

> BTW, where is x-focus-frame defined? I don't see it in frame.el or frame.c.
> (I can see w32-focus-frame defined in w32fns.c.)
>   

Then you are looking at old code. x-focus-frame is defined in xfns.c and
macfns.c, and now in w32fns.c where you found w32-focus-frame.

RE: mouse-autoselect-window

[Drew Adams]

> > Shouldn't it be renamed to `focus-frame'? Don't we usually drop 
> > the `x-' for the generic name, as in `color-defined-p' vs
> > `x-color-defined-p'?
> 
> I think the latter was changed when support for colors on a tty was
> added. There are many functions in the w32 and mac code prefixed with x-.

OK, guess I'm unclear on what the naming convention is.

Re: mouse-autoselect-window

[Eli Zaretskii]

> Date: Wed, 19 Sep 2007 00:13:59 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Drew Adams wrote:
> > Shouldn't it be renamed to `focus-frame'? Don't we usually drop the `x-' for
> > the generic name, as in `color-defined-p' vs `x-color-defined-p'?
> >   
> 
> I think the latter was changed when support for colors on a tty was
> added.

Yes.

> There are many functions in the w32 and mac code prefixed with x-.

Yes, functions available only in the windowed session can (maybe even
should) be prefixed with `x-' or sometimes with `xw-'.

Re: mouse-autoselect-window

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 4 Sep 2007 22:53:14 -0700
> 
> When you move the mouse to a different frame, the mode line is activated,
> and the menu-bar and the tool-bar icons change (depending on the buffer),
> giving the impression that the focus has shifted to the window under the
> mouse in the new frame. But the focus remains in the last window the mouse
> was in in the old frame. The frame border and title bar of the old frame
> show that it still has the focus; it is only the mode line, menu-bar, and
> tool bar that indicate (falsely) the contrary.

This happens with the (default) focus policy on MS-Windows.  For this
Emacs feature to work properly, you need to change the window
manager's focus policy to follow mouse (this is usually the default
behavior on X, or at least it used to be, before the proliferation of
desktop and windows managers that emulate MS-Windows).

> IIUC, on MS Windows there is no way for Emacs to override the
> click-to-focus-frame behavior.

Emacs cannot override that, but you as the user can do that (globally,
for all the windows on your desktop).  One way of doing that is to
install the TweakUI package from the Windows PowerToys collection.
TweakUI has an option to change focus policy to follow mouse pointer.

Re: mouse-autoselect-window

[Eli Zaretskii]

> Date: Wed, 05 Sep 2007 20:33:03 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> For this Emacs feature to work properly

I meant for it to work properly between frames.  Within the same frame
it works properly regardless of the focus policy of the window
manager.

Sorry for being unclear.

mouse-autoselect-window

[Robert Marshall]

Following a recommendation here - I think - I've been setting this to
t and considerably eased my need to click - however I can no longer
drag the mode-line if the frame is split, the moment it moves into one
of the windows it just focusses it.

Is this behaviour expected or is there some configuration I've missed
- or does my cvs need updating...?
 
Robert
-- 
La grenouille songe..dans son château d'eau

Re: mouse-autoselect-window

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Robert Marshall <spam@chezmarshall.freeserve.co.uk>
> Date: Mon, 29 Dec 2003 19:01:15 +0000
> 
> Following a recommendation here - I think - I've been setting this to
> t and considerably eased my need to click - however I can no longer
> drag the mode-line if the frame is split, the moment it moves into one
> of the windows it just focusses it.
> 
> Is this behaviour expected or is there some configuration I've missed
> - or does my cvs need updating...?

Since this is the CVS version, please report such problems to
emacs-pretest-bug@gnu.org.

FWIW, it looks like a bug to me, although with today's CVS I _can_
drag the mode line, but only upwards.

Re: mouse-autoselect-window

[Kevin Rodgers]

Robert Marshall wrote:

> Following a recommendation here - I think - I've been setting this to
> t and considerably eased my need to click - however I can no longer
> drag the mode-line if the frame is split, the moment it moves into one
> of the windows it just focusses it.


What version of Emacs are you using?  21.3 reports:

| mouse-autoselect-window is void
|
| Documentation:
| not documented as a variable.


> Is this behaviour expected or is there some configuration I've missed
> - or does my cvs need updating...?


FWIW, my follow-mouse.el package has a similar problem.

-- 
Kevin Rodgers

Re: mouse-autoselect-window

[Robert Marshall]

On Mon, 29 Dec 2003, Eli Zaretskii wrote:

>> Newsgroups: gnu.emacs.help
>> From: Robert Marshall <spam@chezmarshall.freeserve.co.uk>
>> Date: Mon, 29 Dec 2003 19:01:15 +0000
>> 
>> Following a recommendation here - I think - I've been setting this
>> to t and considerably eased my need to click - however I can no
>> longer drag the mode-line if the frame is split, the moment it
>> moves into one of the windows it just focusses it.
>> 
>> Is this behaviour expected or is there some configuration I've
>> missed
>> - or does my cvs need updating...?
> 
> Since this is the CVS version, please report such problems to
> emacs-pretest-bug@gnu.org.

Will do (wasn't sure that I'd missed something obvious)

> 
> FWIW, it looks like a bug to me, although with today's CVS I _can_
> drag the mode line, but only upwards.

Me too

Thanks

Robert
-- 
La grenouille songe..dans son château d'eau