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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> Out of all these key sequences, some code somewhere has to select the
> one for which the help message will be displayed.

I think this is a mistake.  We should give the answer for all the events
we've seen.  E.g. it may be important for the user to know that mouse-1
is not bound or that down-mouse-1 is not bound.

>> Why string-match on event names rather than use things like
>> event-basic-type, and event-modifiers?
> Lack of knowledge on the part of the person who wrote it (me).

Ah, good, I thought the author had bumped into some odd problem with the
other constructs.

>> >                         (progn
>> > @@ -739,13 +740,31 @@ help-read-key-sequence
>> >                           (sleep-for 0.01)
>> >                           (while (read-event nil nil 0.01))
>
>> We're blindly throwing away events here, right?  Isn't that a problem?
>
> No, it's a filter.  Things like <help-echo>, which otherwise triggered
> the sit-for are now discarded, so that only user events are processed.

But how can we know that we'll only drop help-echo events there?

> I know of nobody who can press mouse buttons as fast as 100 times a
> second.

Yeah, I guess in practice it's not too bad (it can still suffer in cases
where the events don't come from separate user motions but via input
devices which send combined sequences, but it's not too common).

But why not just go around the loop again, and skip the help-echo events
like we do for mouse-movement?  Hmm... oh I guess it's because the
read-key-sequence used here has a timeout whereas the other doesn't...
I'm beginning to understand.
Thanks,


        Stefan