5 ms·

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

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.

mananaysiempre 2y ago
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.)
ku1ik 2y ago
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).
- ComputerGuru 2y ago
  Look up OSC 52 for a standard that lets apps and the terminal exchange clipboard data.
follower 2y ago
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://lib.rs/gh/wez/wezterm/wezterm / https://crates.io/crates/termwiz 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 https://lib.rs/crates/termwiz * "to help with parsing input received from a terminal": https://docs.rs/termwiz/latest/termwiz/input/index.html 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 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 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/terminal/index.html * https://docs.rs/termwiz/latest/termwiz/color/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 https://lib.rs/crates/portable-pty * "Low level escape sequence parser": https://lib.rs/crates/vtparse 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).
- ku1ik 2y ago
  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.

mananaysiempre 2y ago

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.)

ku1ik 2y ago

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).

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

follower 2y ago

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://lib.rs/gh/wez/wezterm/wezterm / https://crates.io/crates/termwiz 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 https://lib.rs/crates/termwiz * "to help with parsing input received from a terminal": https://docs.rs/termwiz/latest/termwiz/input/index.html 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 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 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/terminal/index.html * https://docs.rs/termwiz/latest/termwiz/color/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 https://lib.rs/crates/portable-pty * "Low level escape sequence parser": https://lib.rs/crates/vtparse 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).

ku1ik 2y ago
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.