Terminfo and terminal 'automatic margins' (and modern shells)

Yesterday I wrote about an unexpected difference in how terminal programs handled 'backward line wrapping', which is sometimes known as 'reverse wrapping'. At the time I said that I didn't think terminfo had a capability for this, and if it did it wasn't the 'bw' capability (which is also called the 'auto_left_margin' capability, to go with 'am', 'auto_right_margin'). It turns out the situation is more complex (in both xterm and other programs).

The simpler of the two terminfo capabilities (and terminal behaviors) is 'am'. This is whether printing more characters than the width of the terminal's width wraps around to the next line or whether all of the characters either pile up on the right edge or get lost. Almost all video terminals and basically all terminal emulators behave this way and so their terminfo entries all have 'am' set; it's a standard basic capability that a lot of programs probably don't even bother checking for. There were old (physical) video terminals that didn't do this, but I think you'd search hard to find something without it these days.

(Interested parties can browse the ncurses terminfo database for entries without 'am'. I think printing terminals often lacked it.)

The more complex capability is 'bw', which is whether outputting whatever the 'cub1' ('cursor_left') string is will wrap around on the left side. The normal and typical 'cub1' value is Ctrl-H, although some things set it to 'ESC [ D' or other values (terminals and terminal emulators have been weird over the years). On the surface my entry from yesterday makes it sound like xterm's terminfo should set 'bw', but in fact xterm correctly doesn't. This is because 'bw' is about what happens in general when you output 'cub1' at the start of a line, and in general xterm won't do a backward line wrap (reverse wrap). We can see this (non) behavior on the command line:

$ echo line1; tput cub1 cub1 cub1 cub1 cub1 cub1; echo here

In xterm, you get two lines, each with their text at the left margin. In a terminal program that implements 'bw', you will get one line of output, with 'line1' at the left side and 'here' almost all of the way to the right. Three programs that do this are urxvt, Putty (well, its terminal emulation), and the the Kitty terminal emulator.

Xterm is special in that it effectively implements 'bw' some of the time but not all of it. Xterm will wrap around backward on the left margin only if the original line wrapped on the right margin. This is a specific xterm feature, controlled by its options for 'reverse wraparound' (the -rw and +rw command line options to enable or disable, and the reverseWrap X resource). Xterm's manual page has a wonderful historical artifact where the documentation for -rw mentions:

[...] This is very useful for editing long shell command lines and is encouraged. [...]

This sentence dates from a Unix era before Readline style command line editing was pervasive in shells, so shells read their command lines in 'cooked' terminal mode. Because Readline and other line editing libraries have always had to cope with terminals without 'bw' or xterm's special reverse wrapping, they've always handled the situation themselves, moving the cursor around between lines (and within lines) with direct cursor repositioning as necessary.

Modern terminal programs and libraries such as VTE exist in this environment of pervasive Readline-style line editing, so it's not a crippling limitation if they don't have any sort of reverse wraparound for line input (either full 'bw' support or xterm's limited version).

PS: One can trawl for terminal programs that do this what I consider the right way by looking for terminal programs that explicitly list 'bw' among their terminfo capabilities in their entry (if they have a custom entry, instead of reusing one of xterm's). Unfortunately the ncurses terminfo database suggests that there aren't very many such terminal programs (although there's a bunch of actual serial terminals). Although I'm not sure this is comprehensive and completely correct, since the terminfo entry for screen on our systems doesn't advertise 'bw' although screen certainly behaves that way based on the tput test above (even in gnome-terminal).