I have tried screen-4.3.1 with the correspondingly named patch.

I can confirm that clicks on the bottom line of Midnight Commander (in gnome-terminal + screen) don't work. You don't need mc for that, just manually enable mouse support with the SGR extension:

  echo -ne '\e[?1000h\e[?1006h'

then start a "cat" and click around. Whenever you click in the bottom line or in the rightmost column, only `^[[` appears twice (once for the click and once for the release) which is obviously broken. Sounds like an off-by-one at boundary checking. Also notice the delay which doesn't occur when you click elsewhere, sounds like it's waiting for some data to arrive and gives up on a timeout maybe.

This isn't the only place where such a bug occurs. Start over, this time enable mouse only (1000h) without any extension. Then start cat. As you click around, often only `^[[` appears. Usually there seems to be a rectangle from the upper left corner (let's say the first 24 rows and 120 columns) where clicking works as expected, but further to the right or down they don't. The exact boundaries vary heavily. This is a regression introduced by this patch.

---

As for which protocols to support, I agree with Amadeusz from comment #2 that SGR would be enough. See https://midnight-commander.org/ticket/2662#comment:1 for a detailed example how the old xterm 1005 extension (aka utf8-x10) is backwards incompatible and hence utterly broken. As for the urxvt 1015 extension, as far as I know urxvt is the only piece of software that supports this but not the xterm SGR 1006 one. It would take only a few lines of code to add support there, but the author refused that due to personal reasons (he seemed to be offended that his version wasn't good enough for others). There are plenty of software out there that support SGR 1006 but not urxvt 1015. I wouldn't mind screen putting a bit of additional pressure on urxvt to catch up finally.

Note that the two linked mc bugreports (2662 and 2956) are 5-6 years old, but nothing changed since there in the overall big picture (not just mc in particular).

---

I have not studied and won't study the code and the patch to see how it works, although seeing the bugs I'm not sure I can be confident that screen takes the right approach here. Just to be on the safe side, here's how it should work:

Screen can have split panes, a pane which extends beyond row/column 223 of the host terminal emulator, yet is smaller than 223 rows/cols. The app running there might not have extended mouse support. Yet it's expected that mouse works there.

I'm not sure if screen allows to drag the separator between panes, but if it does (or ever plans to), it should work at all coordinates.

A screen can be detached and reattached from another host terminal emulator supporting another set of extensions, and mouse still needs to work.

In order to implement these, the extension used towards the host terminal emulator should be separated from the extension used within a pane.

Towards the host terminal emulator, whenever screen is interested in mouse at all, it should always unconditionally enable the extension(s in increasing order of preference). Assuming the utterly broken 1005 won't be supported, it should probably enable urxvt 1015 first in case you decide to support it at all, and then enable the new de-facto standard SGR 1006 extension. Depending on the terminal emulator, screen might receive the events in several different formats then, but these formats are clearly distinguishable from each other (unlike in the 1005 mode) so it shouldn't matter. (1006 is a bit tricky here since it encodes the release event a bit differently than others. In fact, in non-1006 modes a bit of guesswork is required to see which button was released (e.g. the leftmost among the pressed ones), whereas 1006 tells you this explicitly.)

As for the windows/panes/whatever you call them inside screen, for each of them the requested extension (or lack thereof) should be remembered, just as by any terminal emulator, and the event should be sent according to that format.

So just as the coordinates themselves are adjusted by screen (the offset of the pane is subtracted), the protocol might also be altered. (And while at it, the set of supported extensions doesn't even have to be the same in the two directions. E.g. if you really care about urxvt, you might want to implement urxvt mode towards the host terminal emulator, but not necessarily towards the apps running inside screen.)

Sorry if that's how it works already.

Thanks! I've tested it with vim and mc. It seems to mostly work, but one thing I've noticed is that in mc I can't use bottom row buttons it just writes '[' character to prompt.

If we want to support big terminal windows we should do this.


There is also
https://lists.gnu.org/archive/html/screen-devel/2014-04/msg00043.html
with similar patch.

One thing to consider is which standard to use (see this - https://midnight-commander.org/ticket/2956 - discussion for example.)

I would prefer only using SGR Extension (1006) - which would probably be solved by patch in e-mail.

See also http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking


Will retest patches again, because I recall having problems with having it to actually work (hence no patch applied).

Many terminals have recently added support for so-called "rxvt" and "sgr" mouse modes which are superior to the traditional "x10" mouse mode. Unfortunately, screen doesn't recognize any of them and filters out their escape sequences.

The attached patch implements support for x10, utf8-x10, rxvt, and sgr mouse modes. It also fixes a long-standing bug where mouse sequences are mangled if they get split across 2+ I/O calls.