Eli Zaretskii [2023-10-23 21:30:38] wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: tomasralph2000@gmail.com,  66655@debbugs.gnu.org
>> 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?
>
> Yes, that's the logic here.  Technically, it happens because clicking
> the mouse emits 2 events: down-mouse-1 followed by another one caused
> by releasing the mouse button, and the first event could cause
> redisplay (as happens in this case) because it generally moves point
> to the location of the click.

How 'bout something like the 100% untested patch below?

Basically, generate a drag only if all 3 are satisfied:
- the mouse has moved (and maybe come back).
- the buffer position has changed.
- the window has not changed (not sure why we have that, but IIUC
  that's a constraint we have on drag events).
And to check the first we simply "mess up" the remembered start position
whenever we emit a mouse-movement.


        Stefan