[screen-devel] [bug #37206] Support for newer terminal mouse modes

[Egmont Koblinger]

Follow-up Comment #6, bug #37206 (project screen):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37206>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/