Hi Thomas, Patrick, everyone,
Could we get this solution incorporated in "xterm" and "xterm-256color", please?
A few years ago I was contributing a noticeable amount of work into getting mouse work beyond col/row 223. I pointed out probably the biggest flaw of the 1005 mode: not being backwards compatible [1], and pointed out one of the big problems with urxvt's response 1015 mode: due to the lack of a unique prefix, parsing would require heavy nontrivial code modification in many applications. This eventually led to Thomas designing the 1006 mode. I put some work into getting some popular terminal emulators and some popular applications support this extension.
Actually, I myself don't even consider the 1006 mode an extension. I believe it's not an extension, it is a bugfix.
An important property of the 1006 mode is that it is backwards compatible, the meaning that an application does not need to know whether the underlying terminal supports this extension or not. An application can just unconditionally enable this mode, and it will receive either arbitrarily large new-style coordinates, or old-style coordinates up to 223. The two kinds of escape sequences are easily distinguishable from each other, there's no ambiguity (as opposed to the 1005 mode).
This led to this extension being incorporated into plenty of popular apps that may or may not use ncurses for screen drawing, but do not use ncurses for input/mouse handling. Examples include vim, emacs, mc, tmux, joe. There definitely were a few others, e.g. at least one of the terminal web browsers (I can't recall which and I'm lazy now to look it up). These apps all (vim might be an exception, not sure) unconditionally enable 1006 mode right after enabling basic mouse support (1000 or 1002), and understand both kinds of incoming mouse coordinates.
What the user sees from this story is: Given a modern enough terminal emulator (except urxvt), mouse in these apps Just Works™.
I expected ncurses to also do the same, and I'm disappointed to see that it's not the case.
First, xterm-1006 supports 8 colors, so I have to choose between mouse coordinates beyond 223, or 256 colors, but not both.
Second, even if there was a terminal description that allowed both, what would its name be? TERM=xterm-256color-1006? This scheme is clearly unmaintainable in the long run (and basically is a step backwards towards TERMCAP where the entire terminal description was squeezed into this variable). With further extensions being introduced over time, it's unreasonable to have all of them listed $TERM. Also, it is prone to breaking if you ssh to a system where this description is not yet installed (so it'd take many years until it could be used reliably).
Third, even with xterm-256color, emulators and distributions were quite reluctant for many years switching into this value (partially because the just-mentioned ssh problem). How long would it take until all popular Unixes and Linux distributions chnaged into TERM=xterm-256color-1006 by default? And what would they say when they'd have to change it again and again and again, let's say this time to xterm-256color-1006-1007-2009-2016? I think it's obvious that this approach cannot work in practice.
As a user, I don't want to have to look up or understand any single bit of this story, my expectation is to make mouse clicks Just Work.
As a developer, I think our most important task is to try to see the bigger picture and understand the needs of users. In its current state, in my opinion ncurses does not support mouse clicks beyond 223, it has a proof-of-concept. I believe it's our responsibility to ship solutions, rather than proof-of-concepts, can-be-hacked-together building blocks, let alone excuses to our users.
As a developer, I believe it's our task to actively push the bugfix to our users so that they receive it even if they don't ask for it, rather than just allow our users to reach out / google for the bugfix.
Could ncurses please be modified to always, unconditionally enable 1006 whenever mouse support is enabled, and parse either kinds of escape sequences? This is the only way we could get rid of the 223-column bug in the foreseeable future, once and for all. This has been implemented in quite a few very popular apps for the last few years without any problem.
Thanks,
egmont