8

Some programs like vim/nano/nload has the ability to use the whole terminal to display its content and upon exiting, the previous terminal output is restored. How do they implement this restoring process?

boh
  • 245
  • 5
    printf \\33\[\?1047h prints the xterm private mode escape sequence for switching to the alternate screen buffer (which does not store a scrollback) and printf \\33\[\?1047l swaps back. – mikeserv Nov 16 '15 at 02:30
  • @mikeserv How about that trap stty -g technique? – RobertL Nov 16 '15 at 02:38
  • 1
    @RobertL - stty affects the termios structure of the kernel-managed serial device. any changes made that way aren't directly related to what the user-space terminal program does. doing stty -echo;printf \\33\[\?1047h will still result in no output when you press keys - the terminal program (like xterm) is reading input from the [pt]ty device and writing it to the screen. it intercepts some escapes and performs certain functions, but not at the same level stty changes do. – mikeserv Nov 16 '15 at 02:44
  • @RobertL - none of that is meant to imply that trap and terminal escapes cannot be usefully combined, of course. they are very handy when paired, actually. – mikeserv Nov 16 '15 at 02:47
  • @mikeserv This may be an over-simplification on a different level, but I always thought that programs like vi (console) or the curses library would save the stty settings, then set raw mode and do all io direct to the tty, filtered through termcap style library (TERM variable), controlling the screen directly, and then restore the stty settings at exit. In that sense, I think the character codes to switch buffers are interpreted by xterm's emulation of the console. In that way I thought the stty settings might apply as the questioner mentioned "use the whole terminal to display".kkk – RobertL Nov 16 '15 at 05:27
  • @RobertL - oh yeah, they usually do. ex is spec'd for canonical input, and vi for raw-mode input. but they don't use shell traps - and they don't affect the terminal through stty - they maintain their own local copies of the global structures. and anyway, that stuff is hard. the canonical vi - as you can see well-documented here, might use t[ci] libs, and might not, but will try to do the right thing always. in any case, they don't do it with escape codes - they're almost always ioctls. – mikeserv Nov 16 '15 at 05:35
  • @mikeserv vi can send escape codes, via the ncurses library (libtinfo5). I don't know what ncurses sends to an xterm. So vi does this: save termios state (stty -g), changes termios state to raw (stty raw), uses ncurses routines, tput for example, to control the full screen display. When done, vi restores the termios to the default line input state (with the results of stty -g). vi doesn't use shell traps and commands, but calls the same underlying system calls as the shell and stty. The model is almost the identical. – RobertL Nov 16 '15 at 06:40
  • @mikeserv Not sure what you mean by hard :-). It's only hard until you know it. To me the question is what do you want to know and how much of it? – RobertL Nov 16 '15 at 06:41

1 Answers1

10

How do they implement this restoring process?

They don't. It's not theirs to implement.

This is the so-called alternate screen buffer being switched in and out. It's implemented in the terminal (or terminal emulator program) itself. The terminal responds to control sequences that are emitted by such TUI programs. The TUI programs control when this happens, but the implementation of what happens is entirely within the terminal. Indeed, the TUI programs don't even have the same model of what is happening. To them, they are switching into and out of "cursor addressing mode".

Not all terminals and terminal emulator programs even have an alternate screen buffer. For example: the terminal emulator programs built into Linux and BSD kernels that provide their kernel virtual terminals usually don't have this capability.

On such terminals, there is no control sequence. The termcap/terminfo database record for the terminal type will, consequently, not have such control sequence; and switching to and from "cursor addressing mode" overwrites the current screen content without saving and restoring it.

vim, nano, and whatnot have no knowledge of this. They aren't doing anything different. They aren't what performs the function. They are simply emitting the control sequences that termcap/terminfo tell them will enter and exit "cursor addressing mode". For some terminals, that have the mechanism, "cursor addressing mode" also means use the alternate screen buffer. For some, that have not, it does not.

Further reading

Stéphane Chazelas
  • 544,893
JdeBP
  • 68,745