bug#66655: 29.1; Clicking buttons sometimes doesn't work

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: tomasralph2000@gmail.com,  66655@debbugs.gnu.org
> Date: Wed, 25 Oct 2023 17:22:41 -0400
> 
> >> In my "in short is approximately" I used `mouse_has_moved` but that
> >> was an oversimplification: in the new code `mouse_has_moved` doesn't
> >> revert to "false" when the mouse returns to the original position,
> >> contrary to what happen in the current code.
> >
> > How exactly does that happen?
> 
> Because as soon as `note_mouse_highlight` receives information that the
> mouse is outside of the fuzz, the var is set to `false` [ And it's only
> set to true when we get the mouse-down event ].

I don't think I understand this explanation.  (Did you mean "true"
instead of "false"?)

You started by saying that your code detects mouse movement, and I
asked how does it detect it.  AFAIR, Emacs doesn't receive
mouse-motion events unless we turn on track-mouse, which we usually
avoid doing.  So this code was originally detecting mouse movement by
comparing the screen coordinates of the down- and up-events.  I'm
asking how is your code different?

> >> The comment above talks about buffer positions (i.e. the Fcar+Fcdr
> >> part of the positions), whereas this `EQ` tests the windows, and the
> >> only relevant comment I see is
> >> 
> >>     /* Different window */
> >> 
> >> which reminds the reader that it's comparing windows but doesn't say why.
> >> Did I miss something?
> >
> > Yes: we can be at the same buffer position, but a different window.
> 
> Right, but what's the problem with that?

You could have redisplay change the windows under your feet, such that
the screen coordinates are the same, the buffer position is the same,
but the window is not the same.  That test wants to emit a drag event
in such a case.  That is my understanding of the test.

> I see now that this was done (in commit
> 6e2d3bce087d30a535b1f01715d7820576ffe390) to handle the case where
> a mouse click causes some window-shuffle, so the up event ends up
> pointing into another window.

Exactly.

> I think my code is immune to this problem since with it we only ever
> generate a drag event if the mouse actually moved.  Which leads to
> a further simplification of the code, see patch below.

I still don't understand the implication of the mouse_has_moved part.