GNU bug report logs -
#66655
29.1; Clicking buttons sometimes doesn't work
Previous Next
Full log
View this message in rfc822 format
> 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
This bug report was last modified 1 year and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.