[Top][All Lists]

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

Re: Question about triggering KEY_MOUSE

From: Bryan Christ
Subject: Re: Question about triggering KEY_MOUSE
Date: Tue, 1 Jan 2019 16:57:51 -0600


That makes sense, but I'm looking in the terminfo for xterm and rxvt (using infocmp) and not seeing XM in either one.  

On Tue, Jan 1, 2019 at 3:59 PM Timothy Allen <address@hidden> wrote:
On Tue, 2019-01-01 at 15:34 -0600, Bryan Christ wrote:
Thanks for the speedy reply.  I see only ESC[?1000h being emitted from the child process (which I assume comes from their app calling ncurses mousemask).  I'm not sure how to "negotiate" that with the child process so that we're both using the same sequences/encodings whether that's 1005, 1006, 1015, or whatever (other than X10).

ncurses uses the "XM" terminfo string to enable mouse reporting (falling back to mode 1000 if no XM string is defined), and inspects that string for the numbers "1000" or "1006" to figure out what encoding to expect.

Some terminfo database entries include an "xm" terminfo string describing the expected encoding, but terminfo.src says "currently there is no interpreter which would use this information to make the mouse support completely data-driven." so you can probably ignore it.

From the application side, the safest way to enable mouse reporting is to enable mode 1000, which is widely supported, then enable mode 1006 - terminals that support mode 1006 will switch to it, terminals that don't recognise it will ignore the request and stay in mode 1000. The responses from mode 1000 and mode 1006 are sufficiently different that there's no danger of confusing them, so applications can just recognise both.


reply via email to

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