bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28658: 27.0.50; [PATCH] double/triple clicking in xterm-mouse-mode d


From: Eli Zaretskii
Subject: bug#28658: 27.0.50; [PATCH] double/triple clicking in xterm-mouse-mode doesn't respect mouse position
Date: Fri, 06 Oct 2017 10:14:13 +0300

> From: Alex <agrambot@gmail.com>
> Cc: 28658@debbugs.gnu.org
> Date: Thu, 05 Oct 2017 18:14:39 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
> >> @@ -290,12 +292,14 @@ xterm-mouse-event
> >>                (xterm-mouse--set-click-count event click-count)))
> >>             ((not last-time) nil)
> >>             ((and (> double-click-time (* 1000 (- this-time last-time)))
> >> +                 (eq x last-x)
> >> +                 (eq y last-y)
> >
> > IMO, 'eq' is not right here: this test should obey the value of
> > double-click-fuzz, whose units on TTY frames are 1/8 of a character.
> 
> I don't understand how to use double-click-fuzz in TTY frames. You said
> that TTY frames can't discern screen position differences of less than a
> character, so then why are the units 1/8th of a character?

I don't know why the units are 1/8th of a character, perhaps so that a
user could set the same value for both GUI and TTY frames.  In any
case, dividing the value of double-click-fuzz by 8 before comparing
with coordinate differences is easy enough, no?

> Is there a way to get the mouse coordinate position in 1/8ths of a
> character to use double-click-fuzz?

I don't think you can get sub-character resolution, but that doesn't
mean double-click-fuzz cannot be obeyed: a user could set the value to
16, in which case a 2-character distance should still be okay.  With
the default value of 3, the second click should indeed be on the same
character, so it will be equivalent to your eq test, but that's only
the default.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]