undefined | Better HN

0 pointshnlmorg0y ago0 comments

> Ignoring the escape sequences a terminal doesn't understand, or doesn't want to deal with is explicitly allowed (required, even) by the ECMA-48 standard.

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.

0 comments

2 comments · 1 top-level

zzo38computer0y ago· 1 in thread

Both kind of "standard" are worth to look at; often existing codes would be suitable. However, there are sometimes some things that there does not seem to be a code for.

hnlmorgOP0y ago

I'm an advocate for creating codes to solve problems. I've literally written a terminal emulator with that in mind: https://github.com/lmorg/ttyphoon -- there I defined codes for graphical features like interactive tables and inlining AI elements in non-intrusive ways.

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.

j / k navigate · click thread line to collapse