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

From: Stefan Monnier <[email-masked]>
Date: Mon, 23 Oct 2023 12:38:35 -0400

> Stefan, I'd appreciate your review of the change, as this is a tricky
> code, where we already had quite a few changes to avoid interpreting
> an up-event as a drag event.

The change looks OK.  But yeah, it does feel like adding yet an
other hack.  The whole:

		       /* Maybe the mouse has moved a lot, caused scrolling, and
			  eventually ended up at the same screen position (but
			  not buffer position) in which case it is a drag, not
			  a click.  */
		       /* FIXME: OTOH if the buffer position has changed
			  because of a timer or process filter rather than
			  because of mouse movement, it should be considered as
			  a click.  But mouse-drag-region completely ignores
			  this case and it hasn't caused any real problem, so
			  it's probably OK to ignore it as well.  */
		       && (EQ (Fcar (Fcdr (start_pos)),
			       Fcar (Fcdr (position))) /* Same buffer pos */
			   /* Redisplay hscrolled text between down- and
                              up-events due to display-line-numbers-mode.  */
			   || line_number_mode_hscroll (start_pos, position)
			   || !EQ (Fcar (start_pos),
				   Fcar (position))))) /* Different window */

is unsatisfactory.  But it's not clear what is the right way to look at
the problem.  As the comment says, we generally want "down+scroll+up" to
be treated as a drag, but not in the current case.  I think the
difference relies on what caused the scroll: if the scroll was the
result of a deliberate act by the user (they moved the mouse after
`down` to cause a scroll), then it's a drag and else it's not?

        Stefan