You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most other languages have a syntax for escaping arbitrary Unicode characters. Having such syntax in just would make some justfiles easier to work with:
Not all valid Unicode characters are printable. And even within the set of printable characters, some text editors don't always do a good job of displaying some printable Unicode characters. Representing these characters as sequence of ASCII characters is not subject to such problems.
If you know the escape sequence of a character you want to use, having escape syntax means you can just type the character rather than needing to find the character in a character map and copy+paste.
Additionally, such syntax would be helpful if the recipe attribute suggested in #647 (comment) gets implemented.
Thinking about just's backwards-compatibility guarantee, maybe the best syntax would be copying Rust's \u{...}, since it allows a flexible and unambiguous number of hex digits?
The text was updated successfully, but these errors were encountered:
This would be great, and I agree that \u{…} is the ideal syntax. It'll require modifying Parser::parse_string_literal, which will be a bit of work to make it process multi-line escape sequences.
Currently
just
strings delimited with" "
or""" """
only support escaping a limited set of characters - https://just.systems/man/en/chapter_30.htmlMost other languages have a syntax for escaping arbitrary Unicode characters. Having such syntax in
just
would make some justfiles easier to work with:Additionally, such syntax would be helpful if the recipe attribute suggested in #647 (comment) gets implemented.
Thinking about
just
's backwards-compatibility guarantee, maybe the best syntax would be copying Rust's\u{...}
, since it allows a flexible and unambiguous number of hex digits?The text was updated successfully, but these errors were encountered: