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

[Drew Adams]

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

Ah yes, thanks.  I see that now on MS Windows too.

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

Sorry, no, I don't buy that.  I mean it's probably true that
most such bindings involve dragging.  But (1) a user who wants
to check what `mouse-N' does won't necessarily use it the same
way when checking with `C-h k' as when using it for its real
purpose.  And (2) the problem with this is that it is not
easily discoverable.

I've used Emacs for quite a while.  OK, I expected both up and
down to be documented.  But even I would likely never have
thought to hold the button pressed for a long time before
releasing, just to see what `C-h k' had to tell me.

If there is no other solution, then I suppose we could live
with this.  But in that case it should be called out in NEWS,
I think.  And if there is a possibility of restoring the
longstanding behavior then I think we should first try for that.

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

Thanks for still taking a look and trying to work this out.