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

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

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

[Juanma Barranquero]

On Wed, Apr 8, 2009 at 23:15, Alan Mackenzie <acm@muc.de> wrote:

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

The trunk still behaves as you describe.

As a first pass, we should fix the docstring of
`mouse-leave-buffer-hook'. It seems wrong for the docstring of a hook
with "leave-buffer" in its name to talk about windows and not say a
word about buffers...

    Juanma

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

[Lars Magne Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> The trunk still behaves as you describe.
>
> As a first pass, we should fix the docstring of
> `mouse-leave-buffer-hook'. It seems wrong for the docstring of a hook
> with "leave-buffer" in its name to talk about windows and not say a
> word about buffers...

Yes, that's a somewhat confusing doc string.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

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

Test code:

(setq mouse-leave-buffer-hook '((lambda ()
				  (message "Leaving %s" (current-buffer)))))

And then mouse-click.  And, indeed, it's run even when not changing a
window.

... Uhm, OK, that was a slightly different thing.  Try this:

(setq mouse-leave-buffer-hook '((lambda ()
				  (message "Leaving %s" (selected-window)))))

The hook is run three times in the selected window, and then it's run
once in the new buffer:

Leaving #<window 110 on sel.el> [3 times]
Leaving #<window 114 on *Messages*>

So the problem isn't just in call-interactively -- the hook is called a
lot -- on any mouse click, and whether we switch windows or not, and
both before and after the switch.

I'm guessing we can't change this at this point, so I'll just adjust the
doc string to reflect the current state of affairs instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no