bug#2932: call-interactively wrongly calls mouse-leave-buffer-hook

[Alan Mackenzie]

Hi, Emacs!

In call-interactively (callint.c L~449), whilst processing `@' ("switch
to the window the mouse was clicked in") in an interactive string, the
code runs the hook `mouse-leave-buffer-hook'.

The code HASN'T CHECKED that this new window is different from the
current window, and even if it is, whether the new window is displaying
a different buffer.  Hence the hook is wrongly invoked when the mouse is
clicked in the current window.

Here is a fragment of the guilty code:

      else if (*string == '@')
        {
          Lisp_Object event, tem;

          event = (next_event < key_count
                   ? AREF (keys, next_event)
                   : Qnil);
          if (EVENT_HAS_PARAMETERS (event)
              && (tem = XCDR (event), CONSP (tem))
              && (tem = XCAR (tem), CONSP (tem))
              && (tem = XCAR (tem), WINDOWP (tem)))
            {                    /* <======================= Check for 
different window missing here. */
              if (MINI_WINDOW_P (XWINDOW (tem))
                  && ! (minibuf_level > 0 && EQ (tem, minibuf_window)))
                error ("Attempt to select inactive minibuffer window");

              /* If the current buffer wants to clean up, let it.  */
              if (!NILP (Vmouse_leave_buffer_hook))
                call1 (Vrun_hooks, Qmouse_leave_buffer_hook);   /* 
<============== Possibly spurious call */

              Fselect_window (tem, Qnil);
            }
          string++;
        }

######################################################

Similarly, DEFUN ("handle-switch-frame" (in frame.c L922) calls the same
hook without checking the new buffer is different.  This is _probably_
also a bug (I haven't checked whether handle-switch-frame's callers
perform this check).

######################################################

Similarly, there are several runnings of this hook from Lisp code, that
don't check the new buffer is different from the old. 


This probably isn't important enough to delay a release.


-- 
Alan Mackenzie (Nuremberg, Germany).