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: 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:

Attachment: 0001-Increase-xterm-click-count-only-within-double-click-.patch
Description: xterm


reply via email to

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