#ecma48 — Public Fediverse posts

I have turned inverse screen on with DEC private mode 5, to give myself the old-time Sun workstation black-on-white framebuffer console experience on the cheap.

Unfortunately, ncurses programs like vi emit a "visual bell" out of the box, instead of the BEL character, because this was the new friendlier way to do bells in shared offices in the 1980s. I remember it.

vb turns private mode 5 on and then off again, because there's no #DECVT control sequence for toggling the current state.

#ECMA48

@stafwag

All in all, getting it right, and compatible with what's out in the world, is quite a task. Many of us end up with entire DEC VT state machines. Because it turns out that it's perfectly legitimate to emit some C0 control characters in the middle of a control sequence. I kid you not.

#ECMA35 #ECMA48

@stafwag

And then once control sequences are parsed correctly, on top of that there are four different types of control sequence used in the wild for setting colours: old AIXterm, XTerm 256-colour, ITU/IEC T.416 faulty, and ITU/IEC T.416 correct.

There's a whole history of a missed field and erroneous use of semi-colons instead of colons, for the ITU/IEC T.416 faulty case.

Plus the "default" colour.

Plus multiple graphics rendtions in a single control sequence.

#ECMA35 #ECMA48

@stafwag

Colours in ncurses. Ouch!

Your SGR parser is a bit simplistic. The basic syntax of control sequences in ECMA-35 and ECMA-48 is a bit more complex than that. More than digits can be parameter characters, and there are intermediate characters to contend with too. Plus there's true CSI rather than its 7-bit alias.

#ECMA35 #ECMA48

I don't know what #less is trying to do, here, without looking at the source; but there's not a terminal in existence that I know of where using CUB to overprint "ESC" with "ESC" actually achieves something.

write(1,"\^[[m\n:\^[[K",8) = 8 (0x8)
write(1,"\r\^[[K \^[[KESC\^[[D\^[[D\^[[DESC",23) = 23 (0x17)
write(1,"\^[[K[\^[[D[",8) = 8 (0x8)
write(1,"\^[[KB\^[[DB\r\^[[K",12) = 12 (0xc)

#ECMA48

Why DEC modifiers less 1? Because adding 1 was a bodge for the days when missing parameters defaulted to 1. Default to 0 has been in ECMA-48 since the 1990s.

Why keyboard⇒DEC-like? Because the keyboard page is where the old non-DEC terminal keys like ExSel, Oper and Again live, and this can easily encompass those in sort-of-DEC-VT manner.

Why consumer⇒SCO-like? Because SCO's extensions tend to deal in PC-like stuff that isn't like old terminals, like AL/AC keys.

#TerminalEmulators #ECMA48

Here's what I invented:

It's the #ECMA48 FNK control sequence with leading parameter characters for private extensions:

USB keyboard page keys have a leading '?' (modelled after DEC extensions).

USB consumer page keys have a leading '=' (modelled after SCO extensions).

Key numbers are the USB usage codes in those pages. Modifiers are encoded as a sub-parameter, DEC values minus 1, allowing multiple keys per control sequence. Sub-parameters default to 0.

#nosh #uservt #TerminalEmulators

Here's what I invented:

It's the #ECMA48 FNK control sequence with leading parameter characters for private extensions:

USB keyboard page keys have a leading '?' (modelled after DEC extensions).

USB consumer page keys have a leading '=' (modelled after SCO extensions).

Key numbers are the USB usage codes in those pages. Modifiers are encoded as a sub-parameter, DEC values minus 1, allowing multiple keys per control sequence. Sub-parameters default to 0.

#nosh #uservt #TerminalEmulators

Here's what I invented:

It's the #ECMA48 FNK control sequence with leading parameter characters for private extensions:

USB keyboard page keys have a leading '?' (modelled after DEC extensions).

USB consumer page keys have a leading '=' (modelled after SCO extensions).

Key numbers are the USB usage codes in those pages. Modifiers are encoded as a sub-parameter, DEC values minus 1, allowing multiple keys per control sequence. Sub-parameters default to 0.

#nosh #uservt #TerminalEmulators

It's amazing to see the built in X text window in cacaflame actually run faster, tunnelled over the exact same SSH connection, than sending the original text and colour control sequences to a terminal emulator to have the terminal emulator render them locally instead of the X server.

It says something about how bloody inefficient streamed ECMA-48 text is. There's a reason that back in the BBS days, people were inventing binary protocols such as AVATAR.

#ECMA48 #X

@jhx @meka

Note that boldface red is not universally bright red. That's a CGAism that the world is gradually seeing rid of. SGR 91 is unequivocally bright red.

Also, SGR 39 is a convenient way of going back to the default colour.

#ECMA48

MobaXTerm fares somewhat better, getting REP of non-BMP characters right.

But conversely it seems unable to comprehend unscii-16, and insists upon unscii font glyphs being only 8 lines high, resulting in massive gutters between rows.

And only unscii has the glyphs for MouseText. They're not in Cascadia Mono, for example.

#MobaXTerm #MouseText #Unicode #ECMA48

Microsoft Terminal goes badly wrong when REP is combined with characters outwith the BMP. Microsoft Terminal Preview is better, but still goes wrong sometimes when (as in the second image here on the bottom scrollbar) told to REP a character.

#MicrosoftTerminal #MouseText #Unicode #ECMA48

@RL_Dane @teamtuck

XTerm, urxvt, GNOME Terminal, and Konsole all have it. As has my terminal emulator. You just have to output the DECSCNM control sequence, just as you would with a real DEC VT.

#DECVT #ECMA48 #T416 #terminal

@RL_Dane @teamtuck

Try inverting the screen and switching between DEC VT520 "light" and "dark". (As you can see, my toolkit has a handy tool for doing this, but it's a simple exercise in printf(1) without.) If that's not satisfactory, then fiddle with the #terminal emulator's palette configuration.

There's nothing that you can do otherwise. In GUIs, applications have "Give me the user's choice of title bar colour" library calls. There's none of that for Unix TUIs.

#T416 #DECVT #ECMA48

@RL_Dane @teamtuck (continued...)

The _only_ control that you have is DECSCNM, an extension to ECMA-48 control sequences from DEC VTs that many terminal emulators (sort of, rxvt getting it wrong, for example) also support.

It basically inverts the sense of the SGR 7 (negative image/reverse video) attribute for the entire display. DEC VT520 doco called it "light" and "dark".

https://vt100.net/docs/vt510-rm/DECSCNM.html

http://jdebp.info/Softwares/nosh/guide/commands/setterm.xml

#DECVT #ECMA48 #T416

@RL_Dane @teamtuck (continued...)
How the ECMA-48, #AIXTerm, and ITU T.416 indexed colours come out is up to the #terminal; as is, indeed, how the default colour comes out.

For these indexed colour schemes there's usually a palette that maps to RGB. Some terminal _emulators_ can adjust the palette. But real terminals didn't even have the 256-colour indexed system, let alone palettes.

The applications pretty much have no say.

#DECVT #ECMA48 #T416
(...continued)

@RL_Dane @teamtuck

The colour #terminal paradigm just doesn't work that way.

Applications can pick from the 8 colours of ECMA-48, or from that plus the additional 8 colours from IBM #AIXterm, or from the 256 indexed colour set of ITU T.416, or from the full ITU T.416 RGB direct colour system.

There are no "modes" or "themes". An application asks for the default colour, or for an explicit ECMA-48, AIXterm, T.416 indexed colour, or RGB direct colour.

#DECVT #ECMA48 #T416
(...continued)