Weird problem with mouse-autoselect-window

Weird problem with mouse-autoselect-window

[Alan Shutko]

I'm having a weird problem with mouse-autoselect-window and was
wondering if other people had seen it.

If I have Gnus open with a summery and article buffer, and start with
the summary buffer selected, then move the mouse over the article
buffer, the first key I hit will be interpreted as if it were in the
summary buffer.  In other words, if I hit "h" after moving the mouse
over the article buffer, it will run the command defined for h in the
summary buffer, gnus-summary-select-article-buffer.

Hmmm... I see the same thing whenever I have two windows open in the
same frame with different modes.  Here's a reproducible case:

emacs -q --no-site-file
C-h v mouse-autoselect-window RET
Click on customize this variable
Toggle the value on.
Set for current session.
Move mouse over *Help* window.
Hit TAB.

You should see "No buttons or fields found".

This is on a Linux box under X, btw.  Anyone see this or have an idea
how I could track it down?  It looks like we're not updating the
current keymap or something, but I don't know where that's set.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Justice is truth in action.

Re: Weird problem with mouse-autoselect-window

[Stefan Monnier]

> I'm having a weird problem with mouse-autoselect-window and was
> wondering if other people had seen it.

I've seen that indeed, although I couldn't reproduce it.
It seems that it works if you wait a bit between the mouse-move and the
key-click.

I haven't had time to track it down (because of the time-dependent
behavior, which makes it difficult to debug in gdb).


	Stefan

Re: Weird problem with mouse-autoselect-window

[Richard Stallman]

    This is on a Linux box under X, btw.

If it is running GNU and Linux, please call it a GNU/Linux box.  This
helps us just as fixing bugs in Emacs helps us--but it is much less
work!

    emacs -q --no-site-file
    C-h v mouse-autoselect-window RET
    Click on customize this variable
    Toggle the value on.
    Set for current session.
    Move mouse over *Help* window.
    Hit TAB.

    You should see "No buttons or fields found".

When you switch frames, Emacs generates a switch-frame
event whose purpose is to wake up read_key_sequence
so it will reread the keymaps of the new frame.
Something similar needs to be done for mouse-autoselect-window.
I would guess that that mechanism either isn't happening
or is working wrong.

Re: Weird problem with mouse-autoselect-window

[Stefan Monnier]

>     This is on a Linux box under X, btw.
> 
> If it is running GNU and Linux, please call it a GNU/Linux box.  This
> helps us just as fixing bugs in Emacs helps us--but it is much less
> work!
> 
>     emacs -q --no-site-file
>     C-h v mouse-autoselect-window RET
>     Click on customize this variable
>     Toggle the value on.
>     Set for current session.
>     Move mouse over *Help* window.
>     Hit TAB.
> 
>     You should see "No buttons or fields found".
> 
> When you switch frames, Emacs generates a switch-frame
> event whose purpose is to wake up read_key_sequence
> so it will reread the keymaps of the new frame.
> Something similar needs to be done for mouse-autoselect-window.
> I would guess that that mechanism either isn't happening
> or is working wrong.

Why is it necessary ?  The select-window event is bound
to handle-select-window which will do the selection (including changing the
current buffer) so when we get back into read_key_sequence, the current
buffer should have been properly switched already.



	Stefan


PS: It might be different for `select-window' events that are in the middle
of a key-sequence rather than at the beginning, of course, but that's
not what is being discussed here.

Re: Weird problem with mouse-autoselect-window

[Richard Stallman]

    > When you switch frames, Emacs generates a switch-frame
    > event whose purpose is to wake up read_key_sequence
    > so it will reread the keymaps of the new frame.
    > Something similar needs to be done for mouse-autoselect-window.
    > I would guess that that mechanism either isn't happening
    > or is working wrong.

    Why is it necessary ?

What is necessary is for there to be an event that wakes up
read_key_sequence.

			   The select-window event is bound
    to handle-select-window which will do the selection (including changing the
    current buffer) so when we get back into read_key_sequence, the current
    buffer should have been properly switched already.

If this event does the job, things ought to work.  But apparently they
don't work.  I can't tell for certain what the problem is, of course,
but the problem is extremely suggestive of a failure for
read_key_sequence to recognize what happened.