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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> If you want a patch that applies, the one below should work.
> Thanks.  It needs some more work.

No doubt.

> E.g., "C-h k C-mouse-1" signals an error:
>   help-fns--analyze-function: Symbol’s function definition is void: nil

Thanks.  I'll look into fixing this...

> and "C-h k C-mouse-3" followed by a menu selection asks for another
> key or mouse click, although it already has got a full key sequence.

... and this.

> In general, I see the idea is to show both down-mouse-N event and
> mouse-N event, both with "C-h c" and "C-h k".  That could be okay, but
> why show undefined sequences?  E.g, "C-h c S-mouse-1" shows this in
> the echo area:
>
>   <S-down-mouse-1> at that spot runs the command mouse-appearance-menu
>   <S-mouse-1> at that spot is undefined

I did not make a special effort to do that, but I also didn't feel like
stripping them away because sometimes it's useful to know what is the
event name.  E.g. you want to bind something to "shifted left mouse
click" because you noticed it doesn't do anything, so you already know
it's undefined, but you don't yet know how to spell it.

I think it's also useful to show to the user than there were two events.

> Also, if both events are bound, I think we should show the mouse-N
> event before the down-mouse-N event, because the former is much more
> important and normally is the one that's bound.

If the down event is unbound it's not shown (this is actually not
a feature I actively tried to obtained: it's just the result of
read-key-sequence dropping the down event if it's not bound).

And I think it's important to preserve the order of the events.
As a side-benefit it reduces the amount of ad-hoc code that needs to
know about what is a down event or a mouse event and so on.


        Stefan