Hi,
JUCE always writes Windows line endings on all platforms. Is this an oversight, or is this intentional?
See juce_OutputStream.cpp:186.
This occasionally trips up other software. For example Bash, which doesn’t merely consider \r to be part of the line, but it also does not treat it as whitespace.
It’s an intentional oversight 
Also current Xcode bug that introduces LF in the middle of CRLF files
That’s an interesting way of putting it. Many other people would classify it as obnoxious non-standard behaviour.
If you have to pick a line-feed style that works best overall, on all the platforms we support, and which is primarily designed for use in text files, i.e. stuff that you’ll open in a text editor, then CR/LF is the one that pretty much any text editor, on any platform, will get right.
It may no longer be the case, but when I first wrote this, maybe 10 years ago, using just a LF would produce files that were unopenable on the major platforms like Windows.
And being a cross-platform toolkit, it would be annoying if the same program produced different types of text output when you run it on different OSes. That’d mess up automated testing, GIT repos, etc. So a single choice of line ending makes sense for this.
“Obnoxious”? Really? You think this was a choice made to deliberately annoy people?
99.9% of the times that people will use the juce file writing classes, they’ll be generating plain text, XML, JSON, etc., where CR/LF is just fine. If you’re using it to create bash scripts, you may be the first and only person to do that, so why do you think this would be a use-case that we’d put at the top of our priority list?
Well not deliberately. But then why?
Version control systems can keep a working copy in the native line-ending style. I thought GIT uses Unix line endings. Automated testing tools can open files in text mode. Getting different text files on different platforms is expected behaviour which happens with every other language and toolkit.
I don’t know what users end up doing with the text files they create. But some of them will run into trouble if the line endings are wrong for the platform they’re on.
On Windows, Notepad (the built-in one) will show files with Unix line endings as a single line. So don’t use Notepad for files coming from OS X or Linux systems. It’s quite bare-bone as a text editor so people regularly working with JSON or XML would get a replacement anyway.
I didn’t come up with the idea of having different line endings on different platforms. But we have to deal with it. Writing the wrong line endings for the platform makes this worse.
Read my post above - I spent some time explaining exactly why.
I obviously don’t. And most devs don’t. But random users use all kinds of stupid editors, and many of the Windows ones choke on LFs. So like I already said above, if you have to pick a line ending that will work in the most cases, CR/LF is the most widely supported.
If you need a file to contain specific chars, then write them yourself. It’s just as easy to write << “\n” as it is to write << newLine.
Actually there’s only one single program in Windows that doesn’t handle LF text files correctly, and that’s notepad.exe. Everything else I’ve tried in Windows read LF-only files just fine.
Slight tangent:
in XCode I can’t get the stupid thing to respect the global CRLF setting, instead I have to manually select it from the right hand pane, which I often forget so end up with lots of annoying whitespace diffs (since the other developer on my project is using VS on Windows and that seems to have no problem respecting the CRLF setting he has).
Anyone know a solution to this? Or would it be possible to have a setting in the Projucer so that it outputs the XCode project with that setting pre-selected? Or should we just resign to having him switch to LF endings?
Don’t get me started on Xcode’s line-ending bugs…
Not only has its save/load been broken for months, but if it decides to put the wrong type of ending into your file so you end up with a mix of ending types, then its undo/redo system starts getting the size of selection blocks wrong (presumably they count CR/LF as one byte or something!), so that when you undo/redo multi-line deletions, it screws up the edit sequence, adding or removing random characters from the text as you go. 
OK, so it’s not just me 
I think we’ll just switch to LF endings then to appease the XCode beast
Just adding the Projucer tool which normalises also line endings:
Projucer --trim-whitespace target_folder
Scans the given folder for C/C++ source files (recursively), and trims any trailing whitespace from their lines, as well as normalising their line-endings to CR-LF.
Note that for any of the file-rewriting commands, add the option "--lf" if you want it to use LF linefeeds instead of CRLF
Can you make Projucer default to LF only? Is there some system-wide permanent way to do this?
I tried running “Projucer.exe --lf” but it still forces CRLF line endings both when editing a file that’s already LF-only and when creating new files.
