-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an additional escape sequence \e. #963
Conversation
This is an idea I had when discussing wren-lang#945 to avoid the need to support octal escape sequences. The only common use for these nowadays is to encode the ESC character (0o33) itself in ANSI escape codes and adding an escape sequence for this will make it a little easier. It's not a new idea as gcc, clang and tcc already support it as a non-standard extension to their C compilers.
@PureFox48 is it One alternative is adding |
@ruby0x1 the front 0 is optional, the escapes where always octal in all known conventions/implementations. |
Yes, @mhermier is correct that the leading Wikipedia has a good summary here. Although |
Adding |
We already have |
Ah ok, I've somehow only ever noticed with a leading 0 but looked it up. Also I forgot \x was there below. I'll make that table a bit clearer. Noting that the Wren page also has this line, which hints that escapes aren't too precious or strictly minimal. "\a" // Alarm beep. (Who uses this?) |
People who do console applications, probably wren-cli use it... was not able to run it since a while because of local changes... |
Yes, I sometimes use |
Minor note: the new escape wasn't documented in this PR but I added it. Thanks for the PR, I think I've used escape stuff enough in wren for unit tests, command line tools and logging that it's not unreasonable to make it cleaner considering the low impact of the change. |
Excellent, thanks :) |
This is an idea I had when discussing #945 to avoid the need to support octal escape sequences.
Probably, the only common use for these nowadays is to encode the ESC character (0o33) itself in ANSI escape codes and adding an escape sequence for this will make life a little easier.
It's not a new idea as gcc, clang and tcc already support it as a non-standard extension to their C compilers.
I haven't added a test as the other escape sequences which represent control characters don't seem to have any.