I wonder how many languages have nice looking "\e" for "\u001b". ruby, perl, bash, anything else?
Inspect ANSI control codes and escape sequences
11–20 of 52 posts
Re: Inspect ANSI control codes and escape sequences
#12Earlier quoted context omitted.
I think this rant is out-of-place here, type "\x1b[: $t" and check for yourself. It parses correctly. You do learn about the allowed character ranges for CSI sequences from ECMA-48 only, not from the Microsoft docs, so i guess the author did their homework.
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
But you seem to think that everyone except yourself is incompetent, are you trying to make up for something?
Re: Inspect ANSI control codes and escape sequences
#13This is a fantastic web util; bookmarked for the future. I wish I had this when I was making, [Dragon's Oven]( https://tronster.itch.io/dragon ). It was a lot of nights and weekends of tinkering with ANSI codes in Typescript. I learned a lot that surprised me, such as: most modern OS's still don't support 16m colors out of the box and that the default Linux shell doesn't support beyond 16 colors. Also no really good…
TheDraw was a cornerstone of my teenage years. I would log into different BBSs just to see their ANSI welcome screens, then I would try and re-create them to learn the art. It was a unique form of animation and I was hoping you had figured out how to get TheDraw working.
I also later used ANSI to make my own cool command line prompts in DOS and later, Linux.
Re: Inspect ANSI control codes and escape sequences
#14"\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.
Re: Inspect ANSI control codes and escape sequences
#15I was a teenager when BBS's were popular. I still sometimes think I would enjoy writing an ANSI parser.
Re: Inspect ANSI control codes and escape sequences
#16Earlier quoted context omitted.
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?
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.
Re: Inspect ANSI control codes and escape sequences
#17I'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.
Re: Inspect ANSI control codes and escape sequences
#18Earlier quoted context omitted.
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…
> 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.
Re: Inspect ANSI control codes and escape sequences
#19No support for blinking text.
Re: Inspect ANSI control codes and escape sequences
#20I would have loved this in 1993. Not that I don't now, but I would have had a real use for it then.