Separating VT and TTY applications

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Multiple issues with terminal applications in GNU/Linux are caused by poorly

thought out notion of terminal application, and consequently very awkward

programming model for terminal emulators.

The proposed solution is to restrict the definition of terminal applications

to full-screen (roughly vi-like) applications, design terminals to support

this kind of applications only, and use a different approach for the remaining

(ed-like, or command-like) applications.

This project provides specific tools to support this split, however, the whole

idea deviates a lot from the common GNU programming model, so it might not be

immediately apparent what those tools are for. The point of this file is to

give an overview of the problems being solved, and how the proposed design

makes things better.

Teletypes and visual terminals

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Modern terminal emulators are software stand-ins for actual hardware devices,

and most of the terms around them in Linux are still references to the hardware.

An (idealized) teletype (TTY) is line printer using an infinite roll of paper

and a keyboard. The stuff typed once never gets over-typed, it remains readable

on the paper. If the output is long, the user can pick the paper and start

reading it from any point (aka scrollback buffer). Powering the thing off

does not erase the paper.

A visual terminal (VT) is a text-mode monitor with a keyboard. Think DEC VT100,

VT220 and the likes. It displays characters on a 2D grid, and allows placing

the cursor anywhere on the grid at will. The characters are non-persistent,

can be overwritten by printing over the same cell on the grind. Overwritten

characters are not recoverable, once it's gone it's gone. VT has no notion

of scrollback buffer, or scrolling for that matter. The cursor can move,

but the grid doesn't. Powering the VT off erases everything on the screen.

The problem with hybrid terminals

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Pretty much every terminal emulator in Linux, including the one built into

the kernel, is written to be both a TTY and a VT at the same time. A lot of

applications in Linux are written with this kind of hybrid terminals in mind.

In a typical Linux interpretation, TTY displays an endless stream

of arbitrary length strings. VT displays a fixed-size matrix with rows and

columns. A hybrid terminal has to map TTY lines onto VT rows and columns,

internally, and maintain some sort of sane relation between them.

The two representations have to behave in different and incompatible

ways with some operations like terminal window resizing and redrawing,

scrollback and text selection, line wrapping. But there is no way to tell

whether a particular part of the input stream was meant to be a line or a row.

A lot of complexity in Linux terminals comes from having this dual

representation, and also having to do things in a way that would work

in with the duality.

Re-drawable terminal applications

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VT applications are essentially GUI applications, with the only difference

being that instead of a pixel-grid window buffer they get a character-grid

buffer. And the buffer is not memory-mapped, instead there's a particular

wire protocol for modifying its contents (the ANSI escape codes).

At any point in time, the application should be able to re-draw the buffer

completely, triggered by SIGWINCH and/or C-l. This is a major reason for

dropping TTY support. TTY apps are not re-drawable, while VT apps, even those

written for GNU/Linux, almost always are (by necessity, either to handle

SIGWINCH or to be able to clean up after stderr spills onto the terminal).

The assumption of redraw-ability allows removing pretty much all persistency

from the terminal emulator, leaving it only in the application which has to

have some persistency anyway.

Re-drawable applications make detach-ability in terminals almost trivial to

implement. GNU screen is a pretty involved application in large part because

it has to implement a hybrid terminal. For a pure VT emulators, re-attaching

to a running applications means just attaching a fd and sending SIGWINCH.

Getting rid of readline

~~~~~~~~~~~~~~~~~~~~~~~

In GNU/Linux, a shell is a terminal application (running on a hybrid terminal)

that combines a specialized text editor and a command interpreter. The text

editor, often by not always provided by the readline library, allows the user

to compose commands which are then processed by the interpreter.

One particularly nasty issue with this is that this approach requires a text

editor to be embedded into anything that wants to be an interactive command

interpreter.

A part of the VT/TTY split idea is moving this text editor into a separate

process. The editor becomes a proper fullscreen VT application that lets

the user compose the command and send it to the interpreter over an IPC

channel, and display whatever results it may return. This way, interpreters

only even need to work in "non-interactive" mode, reading commands from

a pipe and sending output into a pipe, and have no need to interact with

the VT at all.

This user-facing editor/viewer application (the shell) becomes the right

place to implement advanced editor features like syntax highlight and auto-

completion, and also the scrollback buffer for the interpreter output. Having

scrollback tied with the editor, and not in the terminal, allows for instance

scrolling the output but not the command being edited. It also removes the

need to applications like `more` or `less`, and obsoletes isatty().

A different look at the command interpreters

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The relationship between the shell and the backing interpreters mirrors that

of a browser and web backend. Or rather, a networking service client and

the backing services; the connection is always keep-alive, and the running

service instance is expected to maintain its own state (think IMAP).

The "browser" (shell application) sends a stream of requests and renders

the output the backend (interpreter instance) produces for those requests.

Conventionally, the requests are newline-terminated, although that's not

a strict requirement. Other options would work as well as long as the shell

and the backend agree on how the requests should be formatted.

The problem with command output formatting

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hybrid terminal applications, like for instance GNU ls, use ANSI control

sequence (VT protocol) to format their output, query terminal size using

ioctls, and format their output to match terminal width if necessary.

This approach does not work with TTY apps since they aren't running on a

terminal, and besides, the whole idea is awful. Just like with the command

editor, it forces a bunch of application to embed completely irrelevant

text formatting code to produce somewhat decent output. Every application

that does formatted output needs a copy of the same code.

To clarify, GNU ls which is just a file lister needs to calculate visible

width of the file names it is about to output, get terminal width via a VT

ioctl, and format the names in columns to fit the width of the terminal.

The latter part is basically the job of a roff-like text formatter.

But GNU ls is just a file lister! it is not a roff-like text formatter.

Then of course the user does `ls | less` and now `ls` needs to disable its

own internal formatting while `less` is running pretty much the same code

to figure out how to fit strings it got on the screen.

And then the terminal gets resized, and the output `ls` produced does not

fit anymore and `ls` cannot retroactive reformat it because it's not running

anymore. And then the user runs `man` which does something like `nroff | less`

with `nroff` formatting and `less`, well, not formatting. Hopefully.

It's a horrible design that makes no sense and really needs to go.

Better formatting for TTY apps

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So with the VT/TTY split, the solution of the formatting problem is to move

most of the formatting code into the shell application. The backend (both the

interpreters and whatever commands then may run) produce some sort of device

independent markup and the shell application renders that onto the VT it runs

on.

The exact specification of the markup language is not decided yet, but it is

expected to be a lightweight text-coloring similar to inline font switching

in nroff.

One particular feature that it needs is column alignment, probably tab-based:

source rendered

a^b^c a b c

aaa^bbb^ccc aaa bbb ccc

This is a very common output pattern for various tools, and rendering it

properly requires too much effort to do within individual applications.

Especially with arbitrary unicode characters involved.

Implementation notes

~~~~~~~~~~~~~~~~~~~~

As envisioned currently, both VT apps will be run under dedicated supervisor,

ptyhub. Everything else, that is, any non-VT applications, are expected to

follow the TTY model. See ./usrapps.txt for general overview of the supervised

app idea.

It does look like VT emulators and shell applications need to be written

specifically to work with ptyhub. There are really no good way to avoid that.

For command interpreters capable of running external tools, a set of tools

that produce the formatted output will be needed eventually.

The focus on VT applications may prompt some unconventional design decisions

for VT emulators. Automatic line wrapping (moving the cursor to the next line

if the text printed goes over the right boundary) makes no sense for VT apps,

for instance, and actually makes programming them *more* difficult, so most

likely it should be dropped.