bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: bug#1261: 23.0.60; diary-insert-entry and mouse-autoselect-window
Date: Tue, 28 Oct 2008 09:08:04 +0100
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

> 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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]