3 ms·
> 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? Plenty a
by hnlmorg 2y ago
> 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?
Plenty already do:
- Powershell
- Murex https://murex.rocks https://murex.rocks
- Elvish https://elv.sh/ https://elv.sh/
- https://ngs-lang.org/ 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.