ProJucer messes up line endings


#1

When I have a file open in the projucer even if I didn’t change anything, when I press save, all line endings are converted.
In git I use the settings autocrlf = input and in XCode Default OSX/Unix: LF
That’s nasty, because it also messes up the source control inside xcode.
In the code editiong preferences there are only colours to be configured…
Or did I miss something?


#2

Yeah, currently the code editor doesn’t do anything smart in terms of detecting existing line-endings, it just overwrites them.


#3

It also writes even though there were no changes. I often press CMD-S without thinking…


#4

Yep, that’s just the way it works right now. It’s actually very handy as a tool for fixing inconsistent line-endings, since most people who are doing cross-platform work will want to use the Windows-style endings that it currently defaults to. But sure, it’s a feature request.


#5

Ok thanks, I will consider how I will handle line endings in future, maybe I will also use CRLF.
It explains the recurring warnings with BinaryData.*. Should be coupled to the same setting then.


#6

@jules, why would users want the proprietary Windows line endings on non-Windows systems and what inconsistencies is it going to fix if it writes projucer generated files only (except the little user defined section in AppConfig.h)? This messes with the SCM which takes care about such issues. Is a solution (not to touch files that don’t need to be changed and generally leave the line endings alone) still on the todo list?


#7

Personally, I couldn’t care less what kind of line endings people choose, but had to choose a format for the projucer, and chose CR/LF because it’s the most widely compatible one. My criteria was basically to use the format that the causes the fewest number of people to moan about it.

Making the editor smart enough to retain the existing format is a totally sensible feature request, but no promises about when we’d have time to tackle it.


#8

The proprietary CR/LF is used on Windows only. What would it make the most compatible one? Though compatibility is probably not the issue here, its the conflict with the natural line ending the SCM suspects (which should ignore line endings BTW).


#9

When you generate files which use LF, you get a stream of Windows users moaning that it doesn’t open correctly in various crappy editors like Notepad.

Whereas JUCE has used CR/LF for over a decade and nobody has ever complained that their editor couldn’t read a file, on any platform.

You seem to want to draw me into an argument about this, but I’m really not interested in discussing it further. You can set up GIT to automatically normalise endings in your own repo to LF if that’s what you want.


#10

@jules, I am really sorry to bother with thoughts of improvements. Sure notepad needs it and so the macOS projuces should continue to create the line endings for it. BTW. if git is set up to handle line endings it expects the natural line endings of the OS where it runs on. Do I care by myself, what line endings get written on disk, really arguing?
A workaround would be to only write what has changed. Though the solution for a lot of issues was not to require to use projucer at all.


#11

well, not quite. Git can be set up to four modes (github help): always CRLF, always LF, binary and auto. IMHO auto was the reason for many headaches, which is why I can understand the limited excitement to add this feature: it will not work for everybody.

Just thinking what happens, if a file has already mixed line endings? And if you share the repository with other users with varying skill levels this will happen.

IMHO the place to fix it would be the git repository.

But to give the discussion a productive direction, maybe lets focus, how this solution should look like. I think the version XCode provides offers all degrees of freedom needed (if it works, I understand there is a bug in 9.x):
a) select one of the three line endings, that is used when enter is pressed (PJ: fixed on CRLF)
b) on/off switch to convert on save (PJ: currently fixed to ON)

This solution needs no cleverness and has the potential to settle this cause…

(and as I understood, Jules already agreed that it would be good to improve this, it’s just not on the top of the list…)

@raketa: how about doing a pull request? :wink:

EDIT: a question that just occurred to me: would it make sense to count the number of end lines and base the decision on that?


#12

Well, the thing is that the rest of the source files do have native OS file endings. And I don’t intent to change that. git needs to be able to handle native and Windows line endings. This does not seem to work - with whatever git line ending setting. (Though svn can ignore it.)
Although it would be good if git can handle this situation transparently the root of the trouble is in projucer, which should just write native line endings.

I really can’t follow the argument: why would a Windows user complain, if the macOS projucer version writes the correct macOS line endings?


#13

Sigh… Really bored of this discussion. I really don’t see why you care so much.

But…

For starters, it’s meaningless to talk about “correct” line endings, so please don’t use that as an argument.

And secondly, the projucer doesn’t generate files only for the OS you’re running it on - it always generates files for ALL platforms, no matter where you run it. Some of those files will be used on all platforms, some will only be used on a single platform, but it’d be confusing if it generated different content for e.g. Windows project files just because you ran the projucer on OSX.

Also, lots of people will be on a team using different OSes. If their tools generate different output for the same input, things will inevitably get pushed into GIT that contain whitespace diffs, and this makes everyone’s life harder.

So basically, you want your tools to be context-free. If their output depends only on their input, no matter who runs it, then you just have fewer complications to deal with.


#14

workflow:

  • user clones a revision locally
  • git handles the line endings correctly: it translates all to native
  • user runs projucer: all line endings are messed up, making it difficult to find the changes

now committing back requires correcting the line endings otherwise it happens what you describe above:

things will inevitably get pushed into GIT that contain whitespace diffs, and this makes everyone’s life harder.

I am really sorry boring you with issues with your software.


#15

There’s no “issue” with the projucer, it works as intended.

Its job is to generate files. If you modify the content of those files, it’s not the projucer’s responsibility to detect your changes or to figure out how to merge its new content with your modified version. It simply overwrites the original.

If you want them to be different in some way, fine, but it’s up to you to figure out how you manage that. The gitattributes file has a whole bunch of options for enforcing a style, ignoring whitespace differences, etc. You probably want to set that up in a way that works for you.


#16

What’s to say everybody is using git?

I’m not sure that’s my experience with git by default. If true presumably cloning the JUCE repo on my Mac should change all the CRLF line endings to LF? I don’t think that’s what I experience and I don’t recall changing any settings in git to get that behaviour.

I guess it’s a matter of perspective but I find line endings are messed up by other tools inserting or changing line endings to LF, in all the tools I use it’s easily configurable and if there was a problem Projucer has the handy command line tools for cleaning things up.

Having said all that I could see an argument for adding a global preference in the Projucer for handling native line endings and then letting git handle the rest?

Maybe have a look at the Projucer source code and suggest a pull request to speed things up?