GNU bug report logs - #2932
call-interactively wrongly calls mouse-leave-buffer-hook

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2932 in the body.
You can then email your comments to 2932 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: call-interactively wrongly calls mouse-leave-buffer-hook
Date: Wed, 8 Apr 2009 21:15:53 +0000

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

Message #8 received at 2932 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 2932 <at> debbugs.gnu.org
Subject: Re: bug#2932: call-interactively wrongly calls mouse-leave-buffer-hook
Date: Sun, 10 Jul 2011 02:00:41 +0200

On Wed, Apr 8, 2009 at 23:15, Alan Mackenzie <acm <at> 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

Message #11 received at 2932 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 2932 <at> debbugs.gnu.org
Subject: Re: bug#2932: call-interactively wrongly calls mouse-leave-buffer-hook
Date: Sun, 18 Sep 2011 10:17:18 +0200

Juanma Barranquero <lekktu <at> 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/

Message #14 received at 2932 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 2932 <at> debbugs.gnu.org
Subject: Re: bug#2932: call-interactively wrongly calls mouse-leave-buffer-hook
Date: Mon, 19 Jul 2021 16:42:10 +0200

Alan Mackenzie <acm <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.