bug#12204: 24.1.50; Binding mouse-movement interferes with "C-h c" for mouse clicks

[npostavs@users.sourceforge.net]

tags 12204 + confirmed
found 12204 25.2
severity 12204 minor
quit

Eli Zaretskii <eliz@gnu.org> writes:

>     emacs -Q
>     M-x gdb RET
>
>  . Choose some executable, it doesn't matter which one, and type its file
>    name followed by RET.
>
>  . Wait for GDB to start up and show its prompt, then type:
>
>     M-x gud-tooltip-mode RET
>
>  . If your Emacs bzr revision is older than 109615, click the mouse
>    once somewhere in the window.  (Revision 109615 fixed the bug which
>    required that click.)
>
>  . Type "C-h c", and then move the mouse to some tool-bar button or
>    menu-bar menu item, and click on it.  Watch in disbelief as Emacs
>    _executes_ the command bound to that click instead of showing its
>    documentation.
>
>  . Repeat the experiment, but this time, after "C-h c" slowly move the
>    mouse a small ways and watch the echo area.  You will see a message
>    there:
>
>      <mouse-movement> runs the command gud-tooltip-mouse-motion
>
>    The message will disappear after you move the mouse again.
>
> This happens because gud-tooltip-mode binds the command
> gud-tooltip-mouse-motion to mouse-movement event.  The echo area
> display of "C-h c" about that is promptly erased by the next mouse
> motion, so if you are going for a tool bar or menu bar, you won't
> notice it.  Then you will be surprised by the execution of a command
> for which you wanted to see help.
>
> This is not a bug, strictly speaking: the help command works as
> designed.  But I wonder whether we could somehow surprise the user
> less in this situation.

Perhaps describe-key could respect 'use-dialog-box' and popup a dialog
box when the "key" comes from the mouse?

Also, if I understand the gud.el code, it seems like it might be better
implemented if the 'help-echo' or 'mouse-face' text properties were
extended to support a value of 2 functions: a 'mouse-in' and a
'mouse-out' function.