Hacker News Reader

Comment by pzmarzly | Hacker News Reader

I think it is a really good idea to separate vt100 emulation "backend" from the UI. Then all terminal emulators could use a common implementation and just focus on displaying the text, instead of emulating quirks of 50-year old devices.

Using JSON as RPC also seems like a good idea, especially when SSH-ing in, as the language server protocol has shown.

That being said, I don't see this project doing anything (yet?) about escape sequences (for colors, clickable links, mouse and clipboard integrations, setting title and cwd, etc) and handling shortcuts (e.g. translating ctrl-c to sigint). There are very few terminal emulators that get all of that right (I think Kitty, iTerm, WezTerm), so it would be great if this project could lead towards more of them being written.

View on HN

Most sequences used by CLI apps that are supported by popular (widely used) terminal emulators are supported here, i.e. there's good compatibility with VT100/VT220/VT520/etc.

At the moment there's no support for mouse and clipboard - ht uses asciinema's avt for terminal emulation, where this was never needed (although may be added to avt if ht will need it).

Regarding the colors: internally there's full support for standard indexed colors (palette) and RGB. The "getView" call currently returns a plain text version of the screen buffer, stripped of all color information (plaing text is what andyk's headlong project, which uses ht, needs), but we can easily make it return color attributes for each cell or segment of text (either by modifying "getView", or adding complementary "getRichView" or sth like that).

Look up OSC 52 for a standard that lets apps and the terminal exchange clipboard data.

Is there an actually convincing simple protocol for a 2D character buffer? (As opposed to a jumped-up typescript like the DEC terminals.) I’ve tried looking at the IBM tradition, and while it’s certainly different, I wouldn’t say it’s better on this particular point.

(There is also the part where a VT100-style display is a bit more than just a character buffer—there’s rewrapping on resize, for example, which IIUC be on for some lines and off for others—but let’s assume we’re willing to postpone updating window contents until the resize is concluded so can afford to do that on the application/VT100-processor side. Even though that feels like 1995.)

FWIW WezTerm does seem to split much of its "generic terminal" functionality into separate published re-usable crates:

* https://lib.rs/gh/wez/wezterm/wezterm / https://crates.io/crates/termwiz

(Projects that build on this crate includes "ratatui" among others...)

In particular, I note at least these specific feature areas:

* "support functions for applications interested in either displaying data to a terminal or in building a terminal emulator": https://lib.rs/crates/termwiz

* "to help with parsing input received from a terminal": https://docs.rs/termwiz/latest/termwiz/input/index.html

* "Model a cell in the terminal display": https://docs.rs/termwiz/latest/termwiz/cell/index.html

* "parse escape sequences and attach semantic meaning": https://docs.rs/termwiz/latest/termwiz/escape/index.html

* "abstraction over a terminal device": https://docs.rs/termwiz/latest/termwiz/terminal/index.html

* https://docs.rs/termwiz/latest/termwiz/color/index.html

* "cross platform API for working with the psuedo terminal (pty) interfaces": https://lib.rs/crates/portable-pty

* "Low level escape sequence parser": https://lib.rs/crates/vtparse

So, seems like quite a lot there to help avoid re-inventing the wheel for terminal-related functionality (for andyk/ku1ik & others).

ht uses asciinema’s avt as the underlying terminal emulator, so there wasn’t much re-invented here really. It was mostly glueing avt, PTY and JSON RPC together.

Reply on news.ycombinator.com