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


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;
-       }
          /* 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) \

reply via email to

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