XTerm "alternative screen buffer" not supported, makes some apps work less than ideal

[pfalcon]

Some of (fullscreen) console UI applications need to save original screen contents and restore it later. This just best practice to which we, console UI users, got used. That's how less, vim, etc behave. But for some apps it's even more critical, like for Midnight Commander (http://www.midnight-commander.org/) this is even more important, as the whole forkflow depends on the ability to switch between interactive UI and underlying command line.

The way these features are implemented via remote terminal connection is to use "alternative screen buffer" of xterm - with it, there're 2 buffers associated with terminal, which preserve content when switched to another one. The relevant escape sequences are "\E[?47h" to switch to alt buffer and "\E[?47l" to switch back to main. For reference, XTerm control sequences docs are at http://www.xfree86.org/current/ctlseqs.html .

Unfortunately, the sequences above are not implemented, so this bug is about implementing them.

[pfalcon]

Just a random prooflink that people need alt buf support, with some additional details: https://github.com/dvdhrm/kmscon/issues/45 .

[jgbreezer]

Am another user, but wondering if tmux/screen might be a workaround (for Linux shell logins), as I think they can implement a virtual alternative-screen for you.

[pfalcon]

It's not possible to implement alternative screens without terminal support - it needs to either support real alt screens, or provide ability to "read back" screen content, which none of classical terminals offer (linux console has non-terminal way to do that, but then linux console is what you get when you boot bare kernel. Running X, you no longer have linux console, but XTerm which is based on DEC terminal emulation).

Comparing Connectbot and Android-Terminal-Emulator source code, I found the latter arguable much more cleaner and extensible, and implemented XTerm emulation in it to the level enough to run Midnight Commander comfortably. https://github.com/jackpal/Android-Terminal-Emulator

(I obviously don't suggest closing this, because Connectbot's functionality is wider then A-T-E, so implementing better XTerm support in Connectbot would still make sense).

[pfalcon]

It's not possible

I think they can implement a virtual alternative-screen

Actually yeah, if they redirect stdin/stdout and process data streams on them to emulate XTerm, that might work. Not exactly the most convenient (you need to have tmux and friends on target system(s), and know how to use them), but would be worthy workaround to note.

That's similar how I deal with XTerm support, SSH, and A-T-E - I just run standard ssh client in A-T-E to login to remote system and have XTerm support.