bug-ncurses
[Top][All Lists]
Advanced

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

Re: read mouse position beyond column 256 ?


From: Egmont Koblinger
Subject: Re: read mouse position beyond column 256 ?
Date: Fri, 3 Oct 2014 11:17:33 +0200

Hi,

For GPM: I really don't know anything, you should get familiar with it yourself.

For graphical emulators: There's not much more to it than I've described.

DECSET 9 / 1000 / 1001 / 1002 / 1003 enable/disable reporting mouse coordinates, these are the "\e [ ? number h/l" (as in high/low) sequences.  Similarly, 1006 enables/disables the extension.  E.g. echo -ne '\e[?1000h\e[?1006h' enables mouse support with the extension.

Without the extension, you receive \e [ M followed by three bytes, encoding the button, x and y coordinates, respectively.  Button is 0 for left, 1 for middle, 2 for right, 3 for release of any button, higher numbers for wheel scroll.  All values are offset by 32.

With the extension, you receive \e [ < number ; number ; number M/m, numbers are written with ASCII digits and are no longer offset by 32.  For mouse release, the button is no longer 3 but instead the actual button, the trailing character being m rather than M denotes that it's a release event.

There is a termcap/terminfo entry for the legacy \e [ M prefix, but not for the new \e [ < prefix.  This one should somehow be added there (problem being that \e [ < is not necessarily a prefix for extended mouse only, it can later be used for something else as well, with a trailing character other than m/M), or maybe it could just be hardcode it into ncurses.

You might want to start by examining the patches a few applications received. E.g. here's the one that adds it to midnight commander: http://www.midnight-commander.org/ticket/2956 , it's a bit more complicated because it also removes support for the older extension 1015, and one that adds it to joe: http://sourceforge.net/p/joe-editor/patches/108/ .  (If you encounter mouse extensions 1005 or 1015 anywhere, forget about them!  Go for the 1006 mode.)  Similar patches exist for emacs, vim, links/elinks, w3m, probably a few more, you can probably find them in their bugtracker or version control system.

good luck,
egmont


On Thu, Oct 2, 2014 at 2:06 PM, Patrick <address@hidden> wrote:
Hi Egmont

This is really helpful.

So then it's not about ncurses data structures, it's about the protocols it's defaulting to read....

I will need to do a lot of reading to be helpful here.

Could anyone help me put a reading list together? gpm might be one topic but what is the newer protocol?

I assume that reading up on termcap and terminfo would be good.

The more I think about this, the more I want to do this. However I don't want to make promises I can't keep, I do have two disabled and 1 sick people to attend to, I have very limited time, it could take months.

-Pat






On 14-10-02 04:27 AM, Egmont Koblinger wrote:
On Thu, Oct 2, 2014 at 4:51 AM, Patrick <address@hidden> wrote:

I was thinking that if it was not too hard I could to modify ncurses to read beyond row-col 223. Is this code in lib_mouse ? I don't understand the code but it's just over 1500 lines, so it's in the range of possibility for me. Is the ncurses codebase very intertwined or is it fairly easy to understand files like this without understanding the whole codebase?

I don't know the answer to this, sorry, I haven't looked at ncurses's mouse handling.

For graphical terminal emulators: Look for a piece of code where \e[M is recognized and this is followed by reading 3 bytes, and from two of those bytes 32 or 33 is subtracted.

For Linux console + gpm: I don't know.

Would this pretty much be a case of changing a short to an int and than compensating for the change elsewhere ?

Definitely no.

struct MEVENT already has 'int' for the buttons.  So the API/ABI between ncurses and an ncurses-based app already supports practically any coordinates, you shouldn't touch this.

The limitation is not here, the limitation is in the legacy mouse protocol, i.e. in the communication between the terminal emulator and the application (not necessarily an ncurses-based application).

For graphical emulators: You need to make sure that wherever mouse is enabled (\e[?9h or \e[?1000h - \e[?1003h is printed) ncurses also prints \e[?1006h to enable the extension (and correspondingly disables it when disables mouse).  This will switch your graphical terminal to the new protocol.  You can verify this manually:

cat
click with mouse -> nothing
^C
echo -ne '\e[?1002h'
cat
click with mouse -> certain kind of characters emitted, like ^[[M #"^[[M##" -- this format can only encode values up to 223
^C
echo -ne '\e[?1006h'
cat
click with mouse -> another totally different format is emitted, like ^[[<0;3;2M^[[<0;3;2m -- this new format can encode arbitrarily large numbers
^C

Then wherever \e[M is recognized by ncurses, you should also look for \e[< and if you encounter this input, instead of reading three bytes you need to read three decimal integers, delimited by semicolon, terminated by M or m. As opposed to the legacy format, you no longer should subtract 32 from the three values (or probably you need to subtract 1 instead of 33), and if the trailing character is a lowercase 'm' then the first value should be OR-ed by 3 (to fall back to the legacy way of encoding a mouse release).

For Linux console + gpm: I don't know how it works or is supposed to work.

I've already fixed many non-ncurses apps to support this extension, ncurses is yet to come.  Quite some apps (e.g. console web browsers, htop etc.) would benefit from such patch if it would become mainstream, your work would be greatly appreciated!


cheers,
egmont




reply via email to

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