Tried it. It didn't clear the screen.
Surprisingly, to those of us who grew up with home computers, that's not truly the case.
As someone who has done a fair amount of code dealing with ECMA-35 and ECMA-48, today I discovered that node has a has-ansi package.
It is on version 6. It is 7 lines long. It requires 2 other packages. And it is marked beta.
There's an entire separate package with a complete infrastructure of its own for a single regular expression.
This degree of incohesion is mad.
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.
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.
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.
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.
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)
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.
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.
JdeBP
JdeBP