Earlier quoted context omitted.
There is an effort, but it’s mostly built on cruft (which libraries like ncurses or the projects at charm.sh try abstracting away) Also, what would we use besides escape sequences? They are about as small as can be for what they do. Terminals deal with streams of bytes. They don’t just download entire views and render them (normally.) This normally works to their advantage. There’s also the ansi standard control sequ…
> Terminals deal with streams of bytes. 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 meta…
Plenty already do: - Powershell - Murex https://murex.rocks - Elvish https://elv.sh/ - https://ngs-lang.org/
> 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.