[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: |
Alex |
Subject: |
bug#28658: 27.0.50; [PATCH] double/triple clicking in xterm-mouse-mode doesn't respect mouse position |
Date: |
Sat, 07 Oct 2017 15:57:04 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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?
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
Description: xterm
bug#28658: 27.0.50; [PATCH] double/triple clicking in xterm-mouse-mode doesn't respect mouse position, Eli Zaretskii, 2017/10/05