cmd/gofmt: doesn't honor line endings of Windows \r\n terminated source files

[pbennett]

This is present in all current versions of gofmt.
Issue #2242 referenced it, but I was asked to create a new issue for it by Robert.
Robert, we spoke about this at Gophercon to help jog your memory.

Basically, with a \r\n terminated .go file, gofmt will rewrite the entire file to be \n terminated instead. Windows systems use this by default (so this isn't the place for a one-true EOL discussion please) and gofmt should honor the format of the source file. Changing the line endings has a huge impact in regards to source control systems let alone some native windows tools not handling it well.

To keep it simple, I would suggest just using the line terminator from the first line as the hint for the entire file. Determine the EOL chars from the first line - apply on all future writes.

[pbennett]

@griesemer Mentioning you in comment to bring you in... I'm not sure how to assign to you directly.

[bradfitz]

I am strongly opposed to changing this. The whole point of gofmt is to have ONE format. The choice of "\n" vs "\r\n" is no different from the choice between spaces and tabs. gofmt made the decision already.

[pbennett]

Line endings are a platform issue. If you want to support Windows, you need to accept the fact that it is different. Comparing line-endings to the tabs vs. space issues is incorrect. They aren't the same issue, at all. Some Windows tools don't properly handle LF terminated files. None care about tabs or spaces.
gofmt should not be the hammer used to drive home a personal 'one true EOL' battle.
Would I like everything to use the same line endings? Sure, but that's not the reality.
This is fundamentally a Windows platform support issue, and one where Go is not being a good citizen.

[dominikh]

huge impact in regards to source control systems

Can you expand on this?

Some Windows tools don't properly handle LF terminated files

Which relevant tools don't? Only notepad.exe comes to mind, which hardly counts as relevant.

[bradfitz]

Breaking notepad.exe is unfortunate, but I think it's the lesser evil compared to having gofmt not have consistent output.

The only thing that's changed in the 5 years since we last had this conversation in #2242 and on the mailing list is that more Windows editors now support NL-only files.

[pbennett]

This is also an issue with source control systems. Line endings will be checked out based on the local system and expected to be in the local system format - possibly converting to a common format internally. Variations abound in how this is handled by Git, Perforce, etc. So having a file checked in as CR/LF and gofmt changing it to LF is a problem. It is changing the file in a way that can cause checkin problems.
Again, the standard Windows EOL terminator is \r\n - and gofmt should honor that when present.

[griesemer]

I think @bradfitz makes a strong point - we really want to just have one format. The CR/LF vs LF only differences caused a lot of pain in the early days. The language spec was even adjusted to accommodate for that (e.g. CRs are stripped from raw strings https://golang.org/ref/spec#String_literals).

We also know that a huge number of Go developers work on Windows (the majority?), so I'd like to hear what other Windows users have to say here. Specifically, is the fact that gofmt strips CRs from .go files a problem when interacting with whatever version control system is used?

My inclination is that the right approach here might be for an organization that works exclusively in a CR/LF environment to make their own customized gofmt. It's trivial to to that (the cmd/gofmt command essentially uses the go/format package which produces a string containing the formatted source. It's a simple loop to introduce CR\LFs as necessary.)

[alexbrainman]

I don't think I can be considered as average Windows developer. But I never had any problems with Go source files having LF instead of CR/LF.

All standard Go repositories use .gitattributes file (see #9281 (comment) for details) to make git treat all source files as binaries. This helps with "LF instead of CR/LF" problem. Is that correct approach? Is it suitable for others? I am not sure. But works fine for Go Team.

I suppose we need to understand what the real problem here is. Then we can decide what the solution is.

Alex