[JdeBP]

That tells me that you are writing from ignorance, as for starters that's a truly pathetic test that even misses one of the characters that I explicitly mentioned above, let alone thoroughly tests the full range that the specs define. I had an actual poke around the parser code, in contrast to your superficial experimentation. (-: One can, with knowledge, actually find the point where the only three unusual characters that you in fact tested are special cased.

[blueflow]

They are not special cased:

  https://github.com/webpro/ANSI.tools/blob/main/packages/parser/src/parsers/csi.ts#L12

The comment correctly identifies the 0x30-0x3f range as parameter bytes and the following as intermediate bytes. Both the range and the names for the bytes are matching ECMA-48 Chapter 5.4.

But you seem to think that everyone except yourself is incompetent, are you trying to make up for something?

[webpro]

Thanks. Agreed. The way I see it, ignore the noise and there might be something in there.

[JdeBP]

Of course they are. There's a file with all of the special cased constants in, named constants.ts.

Your superficial test tested all three of the special cases in the PRIVATE_OPENERS array, which is what the parser.ts code actually checks. DEC's question mark, which is special cased yet further off on its own, is in reality another "private opener", too, and it isn't limited to DEC (e.g. XQTMODKEYS), and neither does DEC not use the other non-digit parameter characters (e.g. DECDA3).

(There's a hypothesis that DEC's own state machine didn't care where these marker characters were, as it was a simple state machine that had to fit in ROM and probably just set a bitflag. A mistake that we're probably all still making is assuming that they only take effect when in the very first position.)

STRING_OPENERS is another widespread special casing that people do, treating ESC plus a few characters as special rather than handling all of the 7-bit aliases for the C1 characters as the general case.

You seem to think that people who share what the mistakes are and where they themselves have made these very mistakes over the years, to help other people not make them and so that the world continues to remember this hard-learned stuff, is somehow worthy of ad hominems, straw men, insults, and vilification right off the bat. That's a very poor show and you should be ashamed.

[clucas]

> people who share what the mistakes are and where they themselves have made these very mistakes over the years, to help other people not make them and so that the world continues to remember this hard-learned stuff

But then we have this in your post:

> That tells me that you are writing from ignorance, as for starters that's a truly pathetic test

and

> I had an actual poke around the parser code, in contrast to your superficial experimentation.

Perhaps you really did intend for these lines to be helpful and informative? If so, I encourage you to have a moment of empathy for your interlocutor and ask yourself if talking this way is actually the best way to communicate and pass on this hard-earned knowledge.

> ad hominems, straw men, insults, and vilification

I didn't see this from the other poster. I did see it from you. As a disinterested third party, I'm just telling you, you come off way worse in this exchange. Good luck out there buddy.

[webpro]

That's some interesting feedback, thanks for sharing. I'll see what I can extract and apply from it. Please bear with me, this is only my initial take on the whole concept (and as you point out, it isn't that trivial). Didn't have much examples to be inspired by, but we're on our way anyway.

[webpro]

Some of the issues mentioned in this thread have been improved, including private CSI sequences, default param values, and cancellation + substitution.