GNU bug report logs -
#28658
27.0.50; [PATCH] double/triple clicking in xterm-mouse-mode doesn't respect mouse position
Previous Next
Reported by: Alex <agrambot <at> gmail.com>
Date: Sat, 30 Sep 2017 22:07:02 UTC
Severity: normal
Tags: patch
Found in version 27.0.50
Done: Alex <agrambot <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #38 received at 28658 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Alex <agrambot <at> gmail.com>
>> Cc: 28658 <at> debbugs.gnu.org
>> Date: Thu, 05 Oct 2017 18:14:39 -0600
>>
>> Eli Zaretskii <eliz <at> 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?
Yes, I was just confused about the units, but that makes sense. Though
in my GTK Emacs, (frame-char-width) returns 9 instead of 8 for me...
Anyway, here's the patch:
[0001-Increase-xterm-click-count-only-within-double-click-.patch (text/x-diff, attachment)]
This bug report was last modified 7 years and 221 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.