Detect and preserve line separators instead of using system default #340
Conversation
|
Looking at the Eclipse codebase I see similar detection logic in https://github.com/eclipse-platform/eclipse.platform.text/blob/150da4b2675d18f53a2087b74f6e6bed65ce0472/org.eclipse.text/src/org/eclipse/jface/text/DefaultLineTracker.java#L47 |
+ Add .gitattributes for fixtures with a specific eol.
This test hits Properties#store, in which BufferedWriter#newLine applies system default line separators.
|
@ParkerM I'm in the process of merging this one, I've got a local branch that replaces the regex. I'm not sure it's worth actually reusing the eclipse code directly. |
|
10-4, here's a backup in case anything was clobbered by my recent push: https://github.com/ParkerM/spring-javaformat/tree/backup/detect-eol Thanks for looking into it! |
Update `Formatter` so that line endings are now detected based on the contents of the file. This mirrors the behavior of the Eclipse plugin when used in the IDE, specifically the `nextDelimiterInfo` method in `org.eclipse.jface.text.DefaultLineTracker`. See gh-340
|
Thanks very much for the PR @ParkerM. I've now merged this with a few changes to the tests which hopefully mean we don't need |
|
Right on, good call on the test changes (and double good call on swapping out the clumsy regex impl). Just ran a local build on my Windows 10 box and everything's green! 🥳 |
Fixes #280
The current behavior of
Formatter#formatfalls back to the system default line separator when one isn't explicitly specified, causing a bunch of false positives when building on Windows machines with LF configured via.gitconfigor.gitattributes.This modifies the behavior to instead detect a common line separator per source file, and only fall back to system default when one cannot be determined for some reason.
(See linked issue for additional context)