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
grammar clarifications regarding tabs and carriage returns #38
Comments
This
causes a problem when using git on windows, unless I'm missing something. If you clone this gist (which contains no CR) on Windows with the default git configuration, it produces this:
which does not compile:
it is the intended behaviour but IMO it's surprising. Currently as far as I can see you need to either configure git with |
It still surprises me that Git's default configuration is to give you the wrong bytes on windows. Can you clarify which client you're using? is it provided by GitHub? by git-scm.com? by a cygwin package manager (probably not this one)? As much as I'd like to say that Git is wrong (which i kinda did in the last paragraph), the conflict is arising from the concept of a "text file", which many people think is an array of lines rather than a single byte array. Sometimes discussions of character encoding get tangled up in the concept of a "text file" too. But Zig is not interested in all the complexity of "text files", and specifies always UTF-8, always spaces over tabs, always LF line endings. There's some room for accepting and canonicalizing (in zig fmt) unambiguous alternatives for everyone's convenience, but CRLF line endings are officially the wrong way to end lines in Zig (along with NEL, LS, and PS). While it bothers me emotionally that some Git cient on Windows is wasting our time here talking about CRLF line endings, it seems important to get this right to avoid even more wasted time for everyone in the future. With that preamble ramble out of the way: i think we should definitely canonicalize CRLF line endings in multiline string literals to LF line endings. |
I'm using the installer from git-scm. |
Couldn't we just add an error like If mangling the files is an issue, the feature can be put behind a |
could even make |
Yes, I'm thinking along the same lines. Make it a hard error, just like unused locals, and then have |
NL = New Line (0x0a)
CR = Carriage Return (0x0d)
TAB = Tab (0x09)
Inside Line Comments and Documentation Comments
zig fmt
, leaving only NL.Inside Multi-Line String Literals
zig fmt
may not mangle multi line string literals, and therefore the control character TAB are rejected by the grammar inside multi-line string literals.For string literals that want to include CR, TAB, or any other control sequences, they will need to use regular string literals and the
++
operator, or@embedFile
.Whitespace
zig fmt
.zig fmt
.The text was updated successfully, but these errors were encountered: