"\u001b[0m — reset" ... what? Why SGR is not called by name, while, e.g. CUU is? strange... According to which terminal or standard it interperts sequences? Is this tool really helpful? It does look nice! But it does not help with the corneriest cases that would benefit from such tool the most.
Got to start somewhere! Didn't see many examples to get inspired by either. Here's the full table: https://ansi.tools/lookup. This is my initial take on it. Please bring in the corneriest cases! It's open source so bug reports, RFCs and pull requests are most welcome.
I've used the tool sequin in the past to debug issues: https://github.com/charmbracelet/sequin It worked great for me, seems much easier to debug logs directly in the terminal.
Thanks for sharing, haven't seen that one yet. Will see if I can borrow ideas from it.
The parser has, but not the HTML renderer indeed. Using a third-party lib for that currently, but noticed the limitations too. Might replace it with my own!
This is really cool - I've been experimenting with terminal escape sequences recently, and they go deep. Thanks for sharing! Get in touch (email in profile) if you'd like to collaborate.
Thanks! It's all open source (including the tokenizer/parser), so feel free come collaborate on GitHub.
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?
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…
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.
The parser has, but not the HTML renderer indeed. Using a third-party lib for that currently, but noticed the limitations too. Might replace it with my own!
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 character…
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?
Thanks. Agreed. The way I see it, ignore the noise and there might be something in there.
The parser has, but not the HTML renderer indeed. Using a third-party lib for that currently, but noticed the limitations too. Might replace it with my own!
Neat tool, I could see this being handy for debugging TUI tools. I noticed that it works with _escaped_ ESC characters ("\x1b", "\u001b", "\033") but it didn't recognize raw ESC characters that I had in my clipboard. It might be useful to support those (maybe highlight them similarly to how VS Code highlights whitespace characters). The characters show up as numbered unicode error glyphs (I'm on Firefox, if that help…
Thanks, this is great feedback. I'll see what I can do, stay tuned.