Local echo & line discipline

[withoutboats]

I ❤️ issue blogging.

ANSI terminals have no concept of "local echo" - nothing entered at the keyboard of a terminal is written to the screen unless it is written to the output side of the tty connection. However, the tty subsystem of a UNIX kernel does implement an echo feature, in which it echos characters it receives back to the terminal. A number of options exist to modify this feature (such as determining how ctrl characters and backspace ought to be echoed), and it is often combined with the tty's "canonical line discipline," which buffers input until a newline character is received.

These features of the tty make implementing simple programs much easier, but they have two limitations:

• The maximal interface features the tty can provide are still quite minimal (cat with no arguments demonstrates them). You can enter keys and press backspace, and you have access to some shortcuts like ^W. Arrow key navigation doesn't work in any capacity.
• This buffering is performed on the same system as the controlling process. If that is not the localhost, each key must perform a roundtrip before being displayed on the terminal, introducing interface latency.

The simplest solution to the second issue is to implement echo features inside the terminal. The solution to the first is for this echo to be more featureful than the tty's echo.

These are the MVP features of local echo. Each needs to be independently togglable:

• Echo character input (excluding ctrl chars).
• Erase left on backspace, erase right on delete.
• Line buffering.
• Word and line erase characters.
• Horizontal arrow keys.
• Vertical arrow keys (when not in line buffering mode).

Other than the last two points, these are features supported by the tty line discipline. The tty also does a few other things. It generates signals from input; this is basically the only feature that makes the most sense to keep in the tty, because it needs to be on the remote machine but it can't be in the controlling process. Input can be turned off with Ctrl+S, this feature does not seem worthwhile to re-implement.

Beyond this, there are a number of really radical extensions that could be implemented by notty, but may not be good ideas:

• History. Store history of input lines when in line buffering mode and allow it to be accessed and searched through. This is logic that is re-implemented, or not implemented at all, in different shells, repls, and other line-oriented program interfaces.
• Syntax highlighting. Commands which carry some sort of regular expression which will be matched on what's written to the screen later, in order to style it.
• Arbitrary commands: Associate key presses to "echo" arbitrary sequences of ansi codes; if this were powerful enough (meaning among other things that it can map key sequences, and not only keys), this could be used to implement vim/emacs-like interfaces. Of course, only those commands which deal with modifying and navigating the local buffer could be implemented purely locally.
• Scripting language. (I think this is probably a bad idea). Receive scripts that drive terminal behavior, can be registered to trigger on receiving certain input, etc. Technically, this could be used to implement all of the above features. However, scripts cannot be allowed to send arbitrary data to the controlling process, or a program run while in ssh could exit the ssh session and execute arbitrary code from the user's local shell. There are certainly subtler security issues with this, and I am not currently in favor of going in this direction.

[waynr]

Input can be turned off with Ctrl+S, this feature does not seem worthwhile to re-implement.

Just a quick note, Ctrl+S, aka DC3/XOFF is a flow control mechanism by which the remote end may indicate that it cannot handle additional input. The pnuemonic I think of is "suspend" since input continues to queue and will be send once Ctrl+Q, aka DC1/XON is indicated by the remote end.

If we implement local echo at the terminal level, we should consider some means of visualizing for the user the difference in what has reached the remote end vs what is only displayed locally...unless I am misunderstanding, the kind of local echo being discussed here is similar to the local echo a mosh client shows when there is a large amount of network latency.