[Top][All Lists]

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

Re: Possible bug in “kmous” in xterm-256color description

From: Bill Gray
Subject: Re: Possible bug in “kmous” in xterm-256color description
Date: Mon, 2 Aug 2021 10:37:19 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 8/1/21 5:29 AM, Thomas Dickey wrote:

mouse-position reporting is rarely used, judging from comments
made by various people (it would be a performance issue on any remote

   With 'any-event' (xterm-1003) tracking,  you get events if
the mouse moves at all.  With 'button-event' (xterm-1002)
tracking,  you only get them if the mouse moves to another
character cell.  1003 does get you a blizzard of events
from even a small mouse movement.  Even if you're running
locally,  it can be hard to keep up.  Events can be 'lost'.
I have a program that enables any-event tracking,  so that
it can detect if the mouse is hovering over a control and
supply hint text... but the unreliability of mouse control
in that situation has been a problem.

   Is there a way to blend 1003 and 1002 to ask for "any mouse
event,  but only if we're in a new character cell"?  I think
most programs really don't care about mouse moves that remain
in the current character cell.

   Alternatively,  perhaps mouse motion events could be capped
at,  say,  20 a second ("we just reported a mouse move at time
t0;  we've got another one at t0 + 0.02 seconds,  but don't
report another move until t0 + 0.05,  as we may not be done
moving yet").

-- Bill

reply via email to

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