[Feature]: Mouse tracking shouldn't block scrollback

[jace]

Feature description

The xterm control sequence for mouse tracking (code 1000 or 1006) also captures scroll events, reporting them as button codes 64 and 65. This is necessary for apps in alternate screen mode, but hurts usability in regular screen mode because it blocks viewport scrollback.

Termux's behaviour is consistent with other terminal emulators, but may need reconsidering. On a touchscreen, it's far easier to move the cursor in a readline prompt by tapping the screen than by using the soft arrow keys. Many REPL toolkits already have optional mouse support (for example, this zsh plugin), but turning on the feature blocks scrollback, and worse -- an accidental swipe of the screen may invoke unwanted functionality. Eg: the zsh plugin remaps scroll events to command history navigation, so a sloppy tap could accidentally erase user input.

Ideas for how to make this better:

1. Add a preference for mouse tracking: if the display is not in alternate screen mode, turning on mouse tracking will not capture finger dragging as scroll events. Mouse tracking translates dragging with finger down to scroll wheel events #1384 has a conflicting proposal for reporting finger dragging as mouse move events, but I feel these are distinct expectations based on alt screen mode, so both options could co-exist.

2. Implement the passive mouse tracking extension from Contour terminal. (I brought this up in more Mouse Click events #612 too.) This is entirely new functionality however. It's not a stable spec and will need implementations in every REPL, but it'll (hopefully) work across terminal apps as a new modern standard.

Maybe Termux can implement the user preference while waiting for the spec to mature? It seems like an easy fix for a huge usability gain. I'm not aware of any non-fullscreen app that benefits from blocking scrollback.

Additional information

Proposed VT extensions from Contour Terminal: https://github.com/contour-terminal/vt-extensions

[jace]

@trygveaa @fornwall: tagging you both since you've commented on the other issues -- hope that's okay!

[trygveaa]

Hm, I'm skeptical to adding a config option to deviate from the existing terminal emulators. Different terminals behaving differently often ends up with a mess for applications that has to have logic based on which terminal it's running in. And this isn't really something a user should decide on, so I don't think a user option is the best way.

The proposal from Contour looks interesting, but I see that it says to report the same coordinates regardless of scroll position. If so, I'm a bit unsure how you would use it to move the cursor in the shell? How would the shell know the difference between clicking on the last line vs. clicking on the second last line with one line scrolled up, given that they would return the same coordinate?

Note that several terminal emulators already implement the feature you're asking for in a different way, without any mouse reporting to the shell. The way they do it is to have the terminal send left/right arrow key sequences to the shell to move the cursor to where you click. This is supported in at least kitty, xterm, iTerm2, Konsole and DomTerm. I think they all work more or less the same way, though I haven't gone into detail on that.

[jace]

Note that several terminal emulators already implement the feature you're asking for in a different way, without any mouse reporting to the shell. The way they do it is to have the terminal send left/right arrow key sequences to the shell to move the cursor to where you click. This is supported in at least kitty, xterm, iTerm2, Konsole and DomTerm. I think they all work more or less the same way, though I haven't gone into detail on that.

This appears to be via control code 2001, defined as "Enable readline mouse button-1". This will be a great addition to Termux and I'm happy to take a stab at a PR -- I have neither Java nor Android dev experience, but this is a compelling enough reason.

From what I can tell, the 2001 mode is only supposed to work if the text cursor is on the same line as the mouse cursor, which is somewhat limiting on portrait-oriented screens. But better than nothing.

I haven't looked carefully at Contour's proposed extensions, but you're right -- it seems to have been imagined around alt-screen apps.

FWIW, I haven't found any justification for why mouse tracking in the main screen should also capture scroll events. Nobody seems to be using it (apart from remapping to up/down), and Termux already reserves long press events for itself in both main and alt screens. Scroll capture seems like one of those accidents of history that no longer deserves to be honoured.