[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Weird mishandling of bindings with mouse-autoselect-window
From: |
Stefan Monnier |
Subject: |
Weird mishandling of bindings with mouse-autoselect-window |
Date: |
Fri, 11 Apr 2003 19:45:51 -0400 |
I've been using mouse-autoselect-window for a while and has been
bothered by a bug in it that makes it sometimes look up keys in the
wrong buffer. More specifically, if I have buffer-A selected in
window-A and I move the mouse to window-B showing buffer-B and then
hit a key, the command will be executed in B but the key lookup
is done using A's keymaps.
Someone else already reported this problem. I think the patch
below fixes the problem in the case where window-A and window-B
are not on the same frame, but it still doesn't help when they
are on the same frame.
What it does is create a switch-frame event before the select-window
event (in the case when the new window is on a different frame),
such that select-window events only ever really switch between
windows on the same frame.
I think the problem is that the select-window event is bound
to handle-select-window in special-event-map (whereas switch-frame
is bound to handle-switch-frame in global-map).
The use of special-event-map means that the event is processed
directly in read_char and is thus never even seen by read_key_sequence.
I.e. what happens is:
- read_key_sequence calls read_char in buffer-A. Note: it has already
collected the active keymaps.
- you move the mouse
- a select-window event is generated and handled directly in read_char
- you hit a key
- it is returned to read_key_sequence which has no clue that the
current buffer has just been changed, so it uses the already collected
active keymaps which correspond to buffer-A even though we've
already switched to buffer-B.
I think we need to either make GOBBLE_FIRST_EVENT work, or bind
the select-window event in the global-map (rather than in the
special-event-map), or both.
...[time passes]...
Alright I think I got it. It's now handled very much like switch-frame.
Please test.
Stefan
PS: The patch below is only of historical relevance.
--- keyboard.c 24 Mar 2003 19:59:08 -0000 1.732
+++ keyboard.c 11 Apr 2003 21:42:37 -0000
@@ -4002,14 +4027,6 @@
internal_last_event_frame = frame;
kbd_fetch_ptr = event + 1;
}
- else if (event->kind == SELECT_WINDOW_EVENT)
- {
- /* Make an event (select-window (WINDOW)). */
- obj = Fcons (event->frame_or_window, Qnil);
- obj = Fcons (Qselect_window, Fcons (obj, Qnil));
-
- kbd_fetch_ptr = event + 1;
- }
else
{
/* If this event is on a different frame, return a switch-frame this
@@ -4037,6 +4054,13 @@
if (NILP (obj))
{
+ if (event->kind == SELECT_WINDOW_EVENT)
+ {
+ /* Make an event (select-window (WINDOW)). */
+ obj = Fcons (event->frame_or_window, Qnil);
+ obj = Fcons (Qselect_window, Fcons (obj, Qnil));
+ }
+ else
obj = make_lispy_event (event);
#if defined (USE_X_TOOLKIT) || defined (HAVE_NTGUI) || defined(MAC_OS) \
- Weird mishandling of bindings with mouse-autoselect-window,
Stefan Monnier <=