Description
As I develop code in a multi-OS environment (modifying source code through both the Windows 10 IDE and a WSL - Ubuntu shell, collaborators using OS X, etc.), I would really like to avoid source files having all their line endings changed to the system "native" ending by the IDE upon file save as is currently occurring. Even if only one line of code is changed in the Windows IDE with a unix-formatted file, every line is modified on file save due to the change in separator (\n → \r\n), resulting in a heavily polluted git diff/history if the code is being maintained in a repository. I did not notice this behavior in 1.8.5; the fix for issue #6736 is likely what changed.
I have no compelling reason to be using the IDE's "native" line separator in my source files as the IDE's OS is not consistent across the project development. Would it be possible to add the ability to configure the saved file line separator? Perhaps a preferences.txt entry that sets the system line.separator property (if that is all it takes)?
Activity
matthijskooijman commentedon Sep 25, 2018
Ideally, the IDE would just preserve whatever line separator type is found in a file, which is the least invasive approach wrt version tracking. Looking at the issue you linked, the relevant commit is 3e50aee which indeed normalizes all line endings. Before that commit, all line endings would be preserved as-is, except that a native file line ending would be inserted at the end, causing mixed endings.
An ideal fix would be to detect the line endings used (probably just look at the first line ending found) and insert that at the end too, reverting the change linked above? Alternatively, the change above could be kept, but all line endings be normalized to the first one found?
cmsavage commentedon Sep 25, 2018
A global setting sounds like it would be easier to implement, but I agree: the ideal behavior would be to preserve the existing line separator on a file-by-file basis.