Subject:

i love/hate the terminal

Message-Id: https://www.5snb.club/w/terminal/
Linked-From: wiki.

i have Complex Opinions about the terminal. on the one hand, “grid of characters” (except when it’s not a grid, or it’s not characters) is a dogshit way to represent a GUI

but also it’s nice to be able to interact with many different applications easily and in a scriptable way without using the mouse.

Thinking about making a “new terminal”, it needs:

to use a real GUI

base it off qt or something?

simple cases of outputting just text should be simple, but an application should be able to do complex tasks (it shouldn’t suck to use, say, a text editor like this)

network transparency

akin to X11 forwarding (only not shit) or RDP, the actual program behind a terminal should be allowed to be on a remote server, while your terminal acts like a thin client.

I don’t think it should be specified as specifically a stream of bytes, since that would mean you couldn’t, say, send over an image to the client while also sending a more important stream. So probably define an API akin to QUIC, where there’s streams with priorities, where the GUI is modified by the server / required content sent over to the client, and inputs are sent to the server.

For the common case of “it’s all localhost” this wouldn’t be relevant, but even for local applications it should be possible to emulate network latency in order to test how well the application responds.

There is one “main” QUIC stream that handles all input from the client, and gets a stream of DOM tree changes

but “large” transfers (file uploads, image downloads) are punted off to another stream.

actual transparency

this isn’t very much a hard ask, even GUI frameworks can do this easily, but it’s worth keeping in mind, terminals are typically the only thing that has transparency as a commonly set option. So don’t do things that are incompatible with that.

theming

having a set of colors that applications can use is good, but the way terminals implement it now is “well, you have a set of 16 colors that you can change the RGB values of”.

better would be to have named properties that applications can ask for the color of, with a standard set.

You’d need to have applications give a list of properties, so that themes don’t break when applications want to distinguish between 2 cases by adding new properties for them.

For example, say you had a property variable_name, used to indicate variable names used in code. You want to, as the text editor, allow themes to distinguish between mutable and immutable variables.

So you start emitting variable_name mutable and variable_name immutable. Themes that do know about this new thing can match on the mutability of a variable name, and themes that don’t ignore the keyword they don’t recognise, and continue highlighting everything as normal.

(One alternative is to just emit mutable and immutable, while also having a mapping of “fallbacks” that you tell the terminal. So the terminal just keeps following the chain of fallbacks until it finds something it recognises, or it just defaults to default theming)

command handling

each command gets its own GUI space that it can write to. This lets you run multiple commands at once without them clobbering each other.

commands are allowed to keep running even after they’re not the most recent command (but maybe indicate that with a outline?)