But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead?
> There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db.
Everything in that sentence \033[31;1;4munderlines\033[0m the problem to me: If we didn't need to nest metadata into the byte stream, none of us needed wrestle with escape sequences. And that such a thing like the terminfo db even needs to exist speaks volumes about the lengths we have to go to to accommodate for decades of cruft…
Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.
I think it’s a fundamental design choice.
It’s a double edged sword for sure, but it’s important.
It allows terminals to respond very quickly because they never need to wait for an entire data structure to download before displaying information.
It’s such a simple protocol that anyone can hack on it (which is a strength and weakness)
Asking to change that, in my mind, is like asking to change how packets move across a network. It’s all byte streams that get treated as structured data higher up on the abstraction layers.
TUI frameworks like the ones from charm.sh are built atop the base protocol and provide support for structured data much like how our network stack works. That way, as you were saying, application programmers don’t need to worry too much about the underlying “wire protocol”
The issue isn’t that terminals are stream-native or that they operate on byte codes instead of characters.
The problem is lack of standardization of said codes. Which leads to a mountain of edge cases in supporting every known terminal.
That’s the cruft, not the minimal protocol
> Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.
If you have colour codes (et al) sent out-of-band then you need a new kind of terminal emulator which the application then also needs to support. So you do effectively create yet another standard.
Whereas the status quo, as much as it sucks, is largely just vt100 with a few extra luxuries, some of which are as old as xterm. We aren't really talking about having to deal with hundreds of emulation targets, nor even more than one, in most cases.
Where things get a little more challenging is if you want stuff like squiggly underlines or inlined images. There is the beginnings of some de facto standardisation there but it's still a long way from being standardised.
> But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead?
What do you mean by structured data? The escape codes are structured. And any structured dat would be sent as a stream of bytes.
Also consider that if everything had to json messages, that would mean that programs that didn't care about controlling a terminal would need to determine if their stdout was a terminal or a pipe, and properly format content if it was a terminal.
I think the concept of escape sequences is fine.
Although, I do wish that there was a way for the terminal and application to communicate out of bound. In particular that would allow querying the terminal without having to worry about getting unexpected input before the response, and you could send graphics or clipboard data out of band without tying up the terminal itself.
> But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead?
I mostly agree with that. Although it brings up the question of how an rgb color should be converted to a more limited color set. Should it approximate the nearest color for some definition of nearest, or should it ignore the color setting altogether. Though I think it would be better for that complexity to be centralized in the terminal instead of having to be implemented in every application.
> nor should the terminal itself have to support hundreds of emulation targets
I definitely agree with this.
I think we could use a standard terminal control spec that standardizes the things that modern terminals mostly agree on, and removes things that aren't really used anymore. And have a standard mechanism to query for optional or vendor specific capabilities. And write some decent documentation for the control codes (which if it already exists I haven't been able to find, at least in a single place).
There are libraries and frameworks that abstract this for you: ncurses, bubbletea, etc. At some point, every interface is low-level: GPU geometry is a stream of vertices, a program is a stream of bytes. This isn't some terminal-specific tech problem, it's just kind of how computers are.
Abstractions are layered a specific way, though. Layering upon something suboptimal will always be limited by the suboptimal layer.
Ncurses or bubbletea et all may hide it from you, but they still only paint over the bumpy legacy wall below without being able to really improve on it.
"\033[31;1;4munderlines\033[0m" is (again) no worse than a stream of vertices or a stream of object code. Everything is a stream of bytes (well, a stream of bits anyway). Do you want CSS? Lipgloss is not too far off [0].
I read your objection basically as "escape sequences and control codes are noisy garbage"; are you saying something more like "the functionality you can achieve with escape sequences and control codes is fundamentally limited"? If that's the case, I don't see how, especially in the context of a character-based display.
I don’t think it’s suboptimal at all. (How many bytes does it take to change the color of a single word in the terminal protocols vs the web for example)
It’s literally a wire protocol.
It’s minimal and designed to be easily abstracted away.
The suboptimal part is the lack of standardization.
It may be a wire protocol, but it’s also the primary method of interaction with the computer for technical folk. Do we really have to constrain ourselves to a wire protocol here, or is there maybe room for something more user-friendly?
But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead?
> There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db.
Everything in that sentence \033[31;1;4munderlines\033[0m the problem to me: If we didn't need to nest metadata into the byte stream, none of us needed wrestle with escape sequences. And that such a thing like the terminfo db even needs to exist speaks volumes about the lengths we have to go to to accommodate for decades of cruft…
Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.