bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Stephen Berman]

1. emacs -Q

2. M-x customize-variable RET mouse-autoselect-window RET, set value to
Immediate and save for current session.

3. M-x calendar

4. Click mouse-3 on a date in the Calendar, and in the pop-up context
menu click the entry "Insert diary entry".  When doing this, make sure
the mouse pointer remains within the Calendar window.

=> A diary buffer opens in a new window and this is selected, but the
slightest movement of the mouse makes the Calendar window become the
selected window (provided the mouse pointer was within the Calendar
window at the end of step 4).  If instead diary-insert-entry is invoked
by typing `i d' in the Calendar or by clicking "Insert diary entry" in
the Diary menu in the menu bar, then the selected window does not
change, even if the mouse is agressively moved with the pointer in the
Calendar window.  I am using a focus-follows-click policy; these
observations hold regardless of the value of focus-follows-mouse.


In GNU Emacs 23.0.60.12 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-10-25 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[martin rudalics]

 > 1. emacs -Q
 >
 > 2. M-x customize-variable RET mouse-autoselect-window RET, set value to
 > Immediate and save for current session.

I'd never use "Immediate" for `mouse-autoselect-window' if I wanted to
use menus.  I wrote all that delayed autoselection stuff because people
had problems with selecting things from menus and consequently getting
some unrelated window selected.  Please try with some (short) delay.

 > 3. M-x calendar
 >
 > 4. Click mouse-3 on a date in the Calendar, and in the pop-up context
 > menu click the entry "Insert diary entry".  When doing this, make sure
 > the mouse pointer remains within the Calendar window.
 >
 > => A diary buffer opens in a new window and this is selected, but the
 > slightest movement of the mouse makes the Calendar window become the
 > selected window (provided the mouse pointer was within the Calendar
 > window at the end of step 4).

Here the mouse cursor is outside the Emacs frame so I can't reproduce
this.  I suppose you can't move the mouse "around" your Calendar window?

 > If instead diary-insert-entry is invoked
 > by typing `i d' in the Calendar or by clicking "Insert diary entry" in
 > the Diary menu in the menu bar, then the selected window does not
 > change, even if the mouse is agressively moved with the pointer in the
 > Calendar window.

I don't fully understand what you say here.  Where precisely is the
mouse cursor when you start moving it?

 > I am using a focus-follows-click policy; these
 > observations hold regardless of the value of focus-follows-mouse.

They are independent, indeed.

martin

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Stephen Berman]

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

On Mon, 27 Oct 2008 18:25:56 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> 1. emacs -Q
>>
>> 2. M-x customize-variable RET mouse-autoselect-window RET, set value to
>> Immediate and save for current session.
>
> I'd never use "Immediate" for `mouse-autoselect-window' if I wanted to
> use menus.  I wrote all that delayed autoselection stuff because people
> had problems with selecting things from menus and consequently getting
> some unrelated window selected.  

The problem with that is that my principal use of
mouse-autoselect-window is to select a window in a split-window frame,
and I want this to happen immediately.  This conflicts with the menu
selection goal.  I guess it would require an additional mechanism to
satisfy both goals.

>                                  Please try with some (short) delay.

Using a delay makes the problem worse: after clicking to insert the
diary entry, the diary buffer is selected, but as soon as the time delay
of mouse-autoselect-window (I tested with the default value of 0.5
seconds) elapses, the Calendar buffer automatically becomes selected,
without my having moved the mouse at all.  Again, typing 'i d' or using
the menu bar does not show this behavior (instead the diary buffer
remains selected).

>> 3. M-x calendar
>>
>> 4. Click mouse-3 on a date in the Calendar, and in the pop-up context
>> menu click the entry "Insert diary entry".  When doing this, make sure
>> the mouse pointer remains within the Calendar window.
>>
>> => A diary buffer opens in a new window and this is selected, but the
>> slightest movement of the mouse makes the Calendar window become the
>> selected window (provided the mouse pointer was within the Calendar
>> window at the end of step 4).
>
> Here the mouse cursor is outside the Emacs frame so I can't reproduce
> this.  

I don't follow: are you saying when you pop up the diary context menu,
the mouse cursor is *necessarily* outside of the frame?  I find that
hard to believe, given the way it works for me: if the Calendar buffer
is close to the bottom of the monitor display, then I get a context menu
whose "Insert diary entry" entry is within the area of the Calendar
buffer, so when I click it the mouse cursor is within that area as well.

>        I suppose you can't move the mouse "around" your Calendar window?

Sure I can.  Why do you think I can't?  Or perhaps I misunderstand you;
can you be more precise?

>> If instead diary-insert-entry is invoked
>> by typing `i d' in the Calendar or by clicking "Insert diary entry" in
>> the Diary menu in the menu bar, then the selected window does not
>> change, even if the mouse is agressively moved with the pointer in the
>> Calendar window.
>
> I don't fully understand what you say here.  Where precisely is the
> mouse cursor when you start moving it?

Anywhere within the window of the Calendar buffer.  See the attached
image: the mouse-face highlighting and the tooltip show that the mouse
cursor (or pointer, as I called it) is within the Calendar window.  I'm
saying that when I make a diary entry with the context menu, the diary
buffer in the upper window gets selected, but then (provided the mouse
cursor is still within the Calendar window) either by moving the mouse
or if mouse-autoselect-window is set to a delay, then automatically, the
Calendar window gets selected, resulting in the attached image.  In
contrast, inserting the diary entry by typing `i d' or by using the menu
bar does not result in the Calendar window getting focus by moving the
mouse within the Calendar window, nor automatically after the delay set
by mouse-autoselect-window.

>> I am using a focus-follows-click policy; these
>> observations hold regardless of the value of focus-follows-mouse.
>
> They are independent, indeed.

The docstring of mouse-autoselect-window seems to imply they are not
independent: "When customizing this variable make sure that the actual
value of `focus-follows-mouse' matches the behavior of your window
manager."  (The use of "actual" here seems odd; I guess it's supposed to
mean the current ("aktuell" in German) value, but even that sounds
superfluous: I think it's clear enough just to say "the value of
`focus-follows-mouse'".)

Steve Berman


[-- Attachment #2: mouse cursor in Calendar window --]
[-- Type: image/png, Size: 35043 bytes --]

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Stefan Monnier]

> Using a delay makes the problem worse: after clicking to insert the
> diary entry, the diary buffer is selected, but as soon as the time delay
> of mouse-autoselect-window (I tested with the default value of 0.5
> seconds) elapses, the Calendar buffer automatically becomes selected,
> without my having moved the mouse at all.  Again, typing 'i d' or using
> the menu bar does not show this behavior (instead the diary buffer
> remains selected).

I think I see the problem: normally mouse-autoselect-window only kicks
into action when moving from one window to another.  Whereas in your
particular case it kicks in just by having the mouse in another window
than the selected one.  This is indeed undesirable: the behavior you get
with `i d' is done on purpose and required explicit code.  Somehow we'll
need to improve this code to also catch the case where the mouse was
inside a menu.


        Stefan

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[martin rudalics]

 > I don't follow: are you saying when you pop up the diary context menu,
 > the mouse cursor is *necessarily* outside of the frame?  I find that
 > hard to believe, given the way it works for me: if the Calendar buffer
 > is close to the bottom of the monitor display, then I get a context menu
 > whose "Insert diary entry" entry is within the area of the Calendar
 > buffer, so when I click it the mouse cursor is within that area as well.

Here the top of the menu is centered at where I clicked with the mouse,
so only the first two entries of the menu overlay the calendar window
(which is at the bottom of my frame).  The larger part of the menu is
outside my emacs -Q frame though.

 >>        I suppose you can't move the mouse "around" your Calendar window?
 >
 > Sure I can.  Why do you think I can't?  Or perhaps I misunderstand you;
 > can you be more precise?

I initially thought that your problem was that you _wanted to move_ the
mouse from where you popped up the menu to the diary window and got the
calendar window selected instead.  I now understand that you don't want
to move the mouse at all but get the calendar window reselected after
accidentally hitting the mouse when the cursor is within that window.
That's strange and I can't reproduce it here.

 > I'm
 > saying that when I make a diary entry with the context menu, the diary
 > buffer in the upper window gets selected, but then (provided the mouse
 > cursor is still within the Calendar window) either by moving the mouse
 > or if mouse-autoselect-window is set to a delay, then automatically, the
 > Calendar window gets selected, resulting in the attached image.

When I follow Glenn's suggestion to increase the size of the calendar
window so that the menu fits entirely within it, and click on the Insert
diary entry of the menu with mouse-3, a diary window pops up in the
upper half of my frame and the mouse cursor remains in the calendar
window.  When I now move the mouse cursor within the calendar window I
don't get any autoselection.  I get an autoselection _only_ when I move
the mouse cursor to the upper window first and then back to the lower
one.

So I suppose that on your system the following part of handle_one_xevent

                 if (WINDOWP (window)
                     && !EQ (window, last_window)
		    && !EQ (window, selected_window)

for some reason I don't understand has `window' not eq `last_window',
that is, the calendar window is _not_ the window where the mouse moved
last time.  This seems to indict that either the

                 last_window=window;

step failed earlier on your system, or the mouse-3 click moved the mouse
cursor to the diary window, but maybe I'm missing something.

 > The docstring of mouse-autoselect-window seems to imply they are not
 > independent: "When customizing this variable make sure that the actual
 > value of `focus-follows-mouse' matches the behavior of your window
 > manager."  (The use of "actual" here seems odd; I guess it's supposed to
 > mean the current ("aktuell" in German) value, but even that sounds
 > superfluous: I think it's clear enough just to say "the value of
 > `focus-follows-mouse'".)

I wanted "actual" to stand for the "effective" value of this variable
rather than the "default" value (which might not reflect the actual
behavior of your window manager).  Is it really confusing?  In any case
that sentence applies only when you use multiple frames, move the mouse
from one frame to another, and want mouse-autoselection DTRT.

martin

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Glenn Morris]

I tried to debug this some more.

As I said, it only happens with the GTK toolkit, not athena. The GTK
version seems to call handle_one_xevent many more time than the athena
version (event_handler_gdk?). I tried putting a breakpoint at line
6734 of xterm.c, but it was called so often as to be almost unusable.
When I managed to reach the point of pressing mouse-3 in the calendar
window and brought up the calendar menu, gdb was invoked, but my X
session would no longer accept mouse or keyboard events, so I could
not switch to my gdb window. :(

So then I just printed XWINDOW(last_window) to stderr.

It seems that the GTK toolkit associates a popup menu with the topmost
window in a frame, irrespective of which window the menu actually lies
in front of.

When I repeat the initial experiment with the calendar window in the
_topmost_ (it is normally in the lowest) window of the frame (this
requires making the frame and calendar window tall enough that the
mouse cursor stays inside the calendar when selecting "Insert diary
entry"), there is no problem.

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[martin rudalics]

 > So then I just printed XWINDOW(last_window) to stderr.
 >
 > It seems that the GTK toolkit associates a popup menu with the topmost
 > window in a frame, irrespective of which window the menu actually lies
 > in front of.

Would it help to check popup_activated, like

                 if (WINDOWP (window)
		    && !popup_activated ()
		    && !EQ (window, last_window)
		    && !EQ (window, selected_window)

in handle_one_xevent?

martin

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Glenn Morris]

martin rudalics wrote:

> Would it help to check popup_activated, like
>
>                 if (WINDOWP (window)
> 		    && !popup_activated ()
> 		    && !EQ (window, last_window)
> 		    && !EQ (window, selected_window)
>
> in handle_one_xevent?

Not exactly like that, but with a tweak it seems to work (see below).
It feels a bit like covering up the real problem (gtk associating
popup with funny window), but I have no better solution; and indeed
one probably does not want to switch windows when popups are active.

I don't use mouse-autoselect-window, so Stephen please could you check
this works ok?

*** xterm.c	4 Nov 2008 16:47:34 -0000	1.1010
--- xterm.c	4 Nov 2008 18:49:39 -0000
***************
*** 6723,6729 ****
            {
  
              /* Generate SELECT_WINDOW_EVENTs when needed.  */
!             if (!NILP (Vmouse_autoselect_window))
                {
                  Lisp_Object window;
  
--- 6723,6729 ----
            {
  
              /* Generate SELECT_WINDOW_EVENTs when needed.  */
!             if (!NILP (Vmouse_autoselect_window) && !popup_activated ())
                {
                  Lisp_Object window;
  

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Stephen Berman]

On Tue, 04 Nov 2008 13:51:27 -0500 Glenn Morris <rgm@gnu.org> wrote:

> martin rudalics wrote:
>
>> Would it help to check popup_activated, like
>>
>>                 if (WINDOWP (window)
>> 		    && !popup_activated ()
>> 		    && !EQ (window, last_window)
>> 		    && !EQ (window, selected_window)
>>
>> in handle_one_xevent?
>
> Not exactly like that, but with a tweak it seems to work (see below).
> It feels a bit like covering up the real problem (gtk associating
> popup with funny window), but I have no better solution; and indeed
> one probably does not want to switch windows when popups are active.
>
> I don't use mouse-autoselect-window, so Stephen please could you check
> this works ok?

I applied the patch and confirm that it fixes the problem.

Steve Berman

bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window

[Glenn Morris]

martin rudalics wrote:

> Here the mouse cursor is outside the Emacs frame so I can't reproduce
> this.

Increase the height of the calendar window (by dragging the mode-line
up) before pressing mouse-3, so that the "insert diary entry" item is
inside the calendar window.

I see this issue with GTK toolkit, but not with athena.