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

[Stephen Berman <stephen.berman@gmx.net>]

[-- 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 --]