Kittys “modern” way of doing it is still 1979s tech. Kitty just decided it would discard the standard escape sequences because of “reasons”.
Honestly, much as some of Kittys custom sequences have improved things, this particular sequence doesn’t.
Indeed, but what's that got to do with my comment?
I've written a terminal emulator so very familiar how escape sequences are parsed. However your comment doesn't relate to my previous comment at all. At no point did I claim that unsupported codes wouldn't be ignored. What I said was Kitty's codes here are a pointless addition given we already have codes that more widely supported in terminal emulators and have been for several decades now.
> And DECHDL is not "standard" by any means
I assume you meant DECDHL not DECHDL ;) There's also DECDWL for double width too.
I never actually said they standardised.
What you've done here is conflate "standard" (typical/normal/de facto) with "standard" (ISO/ANSI/et al). It's a common way people misconstrue comments when they're looking for arguments rather than reading other people's comments charitably.
There's absolutely nothing wrong with the way I used the term "standard" -- it's pretty clear from the context that I wasn't claiming it is part of ECMA-48.
The reason I did use that term is because DECDHL and DECDWL are both supported on pretty much all DEC terminals (ie vt100 onwards) and xterm. They're a standard part of any hardware terminal or terminal emulator that seeks vt100 compatibility...which is most terminals arguably ostensibly anything created in the last 30 years in fact.
It would be more weird to advocate the use of some uncommon sequence created for one specific graphical terminal emulator that is a toddler in comparison. Yeah I get Kitty is popular, but it's hardly a de facto standard like vt100. Yet here we are -- people reinventing the wheel and thus making the already needlessly complicated problem of feature detection even harder still.
My qualm isn't with defining new escape sequences. It's:
1. calling Kitty's specific double height/width escape sequences "modern" when it's using the same 1970s principles as the original double height/width codes.
2. Kitty reinventing the wheel here when it adds no benefit to the original codes.
It's the same reason I get annoyed that there are 4+ different proprietary codes for inlining images.
All of this continual reinvention of the same ideas just creates more problems than it solves.