bug#29478: 26.0.90; `C-h k' followed by mouse clicks no longer shows down event

[Alan Mackenzie <acm@muc.de>]

Hello, Noam and Drew.

On Mon, Nov 27, 2017 at 20:50:11 -0500, Noam Postavsky wrote:
> tags 29272 + confirmed
> quit

> Drew Adams <drew.adams@oracle.com> writes:

> > The down mouse-button event is no longer listed along with the up
> > event when you use `C-h k' with a click event.  Dunno whether this was
> > by design or is an oversight.

I think if you press and hold the mouse button for (default) half a
second, when you finally release it, C-h k will report the down mouse
event.  At least this is how GPM behaves for me on a Linux tty.  This
seems to make sense, because anything bound to a down mouse event is
going to be something like a drag event, where the mouse button is held
for an extended period of time.

> Looks like oversight.  Possibly related to Bug#29272.  The following
> seems to fix it for me, but I'm having trouble convincing myself that
> it's the right thing.

> --- c/lisp/help.el
> +++ i/lisp/help.el
> @@ -738,7 +738,7 @@ help-read-key-sequence
>                           ;; spuriously trigger the `sit-for'.
>                           (sleep-for 0.01)
>                           (while (read-event nil nil 0.01))
> -                         (not (sit-for (/ double-click-time 1000.0) t))))))))
> +                         (sit-for (/ double-click-time 1000.0) t)))))))
>            (list
>             key
>             ;; If KEY is a down-event, read and include the


> Alan, I believe you've been working on this code recently, any thoughts?

That I'm redoing some of the underlying C code after a suboptimal patch
some days ago, and this seems to have some effect on the mouse events
reported for C-h c and C-h k.

Eli has already reported that the proposed negation of that condition
would break the patch and lead to annoying infinite loops with mouse
events.

I think this code still may have some way to go before reaching its
final state.

-- 
Alan Mackenzie (Nuremberg, Germany).