I have no idea what’s expected for 9.1. I’m hoping someone will give it a go and report back here!
can’t see much has been fixed - file search still broken, autocomplete somewhat random - warning/error list still taking a long time to resolve sometimes.
not holding breath here - I remember Apple taking 5 months to fix the codesign crash which you’d think would have been a somewhat high priority
What a bunch of bull… I honestly don’t understand this. I submitted reports that after 3 or 4 weeks turned into “dupes,” so others have chimed in too, but they aren’t addressing it. Very annoying.
I’ve been using the 9.1 beta…slightly better/more stable than the original 9.0. Nothing earth shattering here, although I really hate how slow and far behind the error checking is compared to 8.x. Probably all in the service of Swift.
That’s indeed an annoying practice… they could at least show, if there is at least any progress…
Apple: For security and privacy reasons, we don’t provide access to the original bug yours was duped to.
That’s so convenient and double speak… grr…
Absolutely. And to make matters worse, they seem to fix a ton of bugs that aren’t even important compared to these issues, that I wouldn’t even know existed if they weren’t documented. Its frustrating.
As someone who has never had to deal with fixing line endings, can someone explain how they are going about committing changes in Xcode 9 and dealing with the issue of the entire file being flagged as a change? I don’t want to commit the entire file, any help here would be greatly appreciated.
In Xcode go to
Xcode >> Preferences... >> Text Editing >> Editing. From here you can change the default line endings and there is also a
Convert existing files on save option.
To conform with the way JUCE tends to do things I would recommend setting line endings to
Windows (CRLF) and enabling the
Convert existing files on save option. I think by default it’s set to
macOS / Unix (LF) and the option is enabled. If you go for these settings you can make sure all your files are using CRLF line endings by calling the Projucer from the command line with the following argument…
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.
Except thate there is currently a bug with Xcode that might not want to save with CRLF end of lines even if configured to do so; I suggest if that happens to use a text editor (like TextWrangler.app) for converting the end of lines as long as this bug remains in Xcode.
Thanks for the information, really appreciate it. However, switching the options to Windows line endings and setting the option to convert on saving isn’t undoing the new changes caused by Xcode. In fact, I’ve tried just about every combination of setting and each one is the same, saving a file causes it to flag the whole file. I’m currently using the SoundRadix Python script, which works beautifully to fix my files (thank you guys), but is still an extra step in the end, which is not as desirable as just having a properly functioning IDE.
I’m using this now, it works flawlessly for me. Entirely reverts my file back to JUST the changes I make. Thank you very much for sharing this with us! Really wish I understood Python this well…
I just saw the 9.2 beta posted. Also, Apple requested I send them a screen recording showing how long error messages take to disappear during compiling (@yairadix mentioned this in the original post). So, Bug reports do NOT go unheard. Have you guys submitted your bug reports for XCode 9?
I’ve submitted maybe 5 or 6, even back during beta, and those didn’t get addressed in official version 9 release or the latest update, even after they messaged me back and asked for further proof, which I provided.
Also, it seems that the beta that is currently posted is 9.1 beta 2.
Sorry if I seem to be on a rant about this, but it just blows my mind that they aren’t really even trying to fix this. I’m not even coding more than a few hours a day, I don’t know how these other avid Xcoders, who use it all day long, are able to deal with it.
the 9.2 beta is now downloadable.
Nice, must’ve been a regional thing why I didn’t see it until now.
9.1 Documentation doesn’t seem to have any fixes for end line error, searching error, etc…
Looks like the 9.2 beta is much better. Line endings preferences and code locations seem to be working
Maybe they’ve got the guy who fixed the iOS calculator assigned to it
Line endings are fixed on 9.1 for me. I can save files and only new changes are flagged in the diff.
Global searching seems to work now, but I haven’t tried it enough to feel confident in it being entirely fixed…
Autocompletion in some areas is still broken (inserting a class, no semicolon).
Structure highlighting is still broken in some cases.
Haven’t checked if refactoring has been fixed, I need to test it on a class to make sure the files have been changed as well.
Code folding is still missing. A feature they removed from the editor and haven’t put back yet.
At any rate, this is an improvement.
Anyone else want to confirm?
Line endings not fixed for me (as of Xcode 8.1 and Xcode 9.2 beta (9C32c)): when opening a CRLF file, newly edited lines are LF, still a nightmare (and even worse because it’s even less noticeable in diffs) because you end up with files with mixed CRLF & LF line endings. My bug report on entire files marked as “fixed” I’ll post a new bug report about this new behavior.
Hmm, strange. Hope they sort this out for every case. Until then, the Python script written by the SoundRadix guys (linked above) works perfectly and is extremely fast. Just put it in your directory that your .git repo is in and run it before you commit. It is an extra step, but if you keep terminal open and have ran the command once, its faster to click the up arrow (back one in history) and hit enter than opening up an additional editor to fix the lines each time. It worked great for me during the week or so I needed to use it.