Hacker News Reader

Comment by metroholografix | Hacker News Reader

https://www.ecma-international.org/publications-and-standard...

The relevant ECMA standards are full of crazy bullshit that, to the best of my knowledge, nobody has ever implemented in any hardware or software terminal, like control sequences to make lines of text run vertically (SPD), or to fully justify text (JFY), or to use a Fraktur font (SGR 20). They're also incomplete -- they go into very little detail explaining what various control sequences should do, especially in exceptional circumstances, and they don't discuss Unicode at all (as they haven't been updated since the early 1990s).

Hi I'm one of the people cited by the article. Fraktur is awesome. I implemented it in my terminal. https://github.com/jart/cosmopolitan/blob/c6bbca55e9f977e386... Now that unicode makes it easy, there's no excuse not to have fraktur!

Wow, okay, guess I can cross that one off my list of "ECMA-48 features nobody implements".

There's still plenty left on that list, though -- including at least one escape sequence I'm fairly certain was included as a joke (SPQR).

I can think of a use case or 2. Thermal printers (for those wanting old timey unix line printing interfaces) or e-ink displays in console mode.

The joke in SPQR is the name -- https://en.wikipedia.org/wiki/SPQR

The functionality is legitimate (although I doubt anyone uses it), but the name is pure silliness -- much like the PowerPC "eieio" instruction.

Good to see you've added support for that but the cynic in me can't help wondering if that ANSI code is even needed. While you're right that unicode makes it easy to support, it's also even easier to output the Fraktur characters directly from the CLI application and do away with that particular escape code entirely. The bonus in doing that is you then support more terminals in the process since unicode is more widely supported than the Fraktur escape sequence.

This isn't me being critical in what you've done though. More of an adjacent commentary about the state of ANSI escape sequences.

Yes I understand. That's why the support is for the lulz. It's difficult to communicate tone over text.

Not all terminal emulators follow that completely. Most only include a subset and some include their own proprietary escape codes too (like iTerm and Terminology have codes for rendering images. tmux has an escape code for changing the session title).

Then there's other specs not included in that doc even outside of the aforementioned proprietary codes. Like Sixel, conventions on non-POSIX terminals, etc. Also lets not forget the popular-but-not-standardised conventions like the hyperlink escape codes (which I personally think shouldn't exist in the first place....but that's another topic entirely).

Even standard ASCII characters can differ from one platform to another. Backspace being a classic example: ISO 646 describe it as ^H whereas ASCII 1963 has it as ^?

This mess of differing compatibilities is exactly why termcap is a thing.

Being an author of a readline library, this is a topic quite close to my heart :)

hTerm and also IIRC kitty have image-rendering escape sequences too.

Not familiar with hTerm. Got a link to the project?

Would be good to add support for that to my image rendering library: https://github.com/lmorg/murex/blob/c77b893a58a682735ad7502c...

Upstream: https://chromium.googlesource.com/apps/libapps/+/HEAD/hterm

Fork used by iSH: https://github.com/ish-app/libapps/tree/master/hterm

I looked at the docs (https://github.com/ish-app/libapps/blob/master/hterm/doc/Con...) and it appears to use the same protocol as iTerm.

Here's an implementation: https://github.com/ish-app/libapps/blob/master/hterm/etc/hte...

Thank you

> > ^? is the code for the [DEL] or [DELETE] key on physical terminals, that's why it's an ASCII standard.

> When the PC bucket keyboards came, IBM in their usual idiocy simply put the [BACKSPACE] key where the [DELETE] key normally is, and what's worse, they made it not only move back one space but delete too. Thus came the sadness of everlasting redefining of deletion to be ^H when using a PC bucket keyboard.

Indeed. And to confuse things even further, the [DEL] key on IBM keyboards sends the following ANSI escape sequence: [27 91 51 126]

So we now have 3 different standards for deleting characters (and that's before you start looking at the escape sequences for deleting rows, nor supporting vi and/or emacs/readline bindings).

Reply on news.ycombinator.com