When I save a file in Fire on OSX, what encoding does it use?
It seems that if I have a UTF-8 swift file included both in an XCode project and Fire, Fire reads it fine. But as soon as I edit and save in Fire, the file becomes unusable in XCode - it starts giving a compile error along the lines of “No expressions allowed at the top level” - it’s seemingly choking on control characters at the start of the file.
I can’t fix this by saving or changing the encoding in XCode.
The only work around at the moment I have is to open the file in Sublime Text and do a Save with Encoding -> UTF-8, which makes XCode happy again.
bump? can you just let me know what encoding Fire saves with by default?
Thanks
Jon
It looks like Apple’s Swift compiler cannot handle UTF-8 header bytes in .swift files. That’s very disappointing and weird, since that’s actually how NSString saves UTF-8 files by default. I’ll have to investigate and check if I can avoid that. But I suggest you also log an issue with Apple, since these are perfectly valid UTF-8 files and their compiler should handle them just fine…
wow that’s awesome.
I thought it might be to do with the fact that XCode had the file open at the time it was changed in Fire, but nope, if you change the file with XCode closed it still bitches when you open it up again
1 Like
Just letting you know this is the most annoying thing about Fire - it basically means we can’t use it as an editor, as anything saved with Fire screws up XCode. And if you fix the encoding, Git then thinks the whole file has changed and gives massive diffs.
So our workflow currently is:
- Write and compile in XCode
- Compile in Fire
- Take the line numbers of Fire build errors, and find it in XCode. Try and fix the issue there.
- Repeat (and curse)
Somehow, since build .1917, it’s now not happening to one of our developers, but we have no idea what’s different about his environment. It definitely still happens for me.
Really, though, this is something Apple needs to fix. It’s a bug in their compiler.
In fact, i cannot cleanly fix this, not without adding massive overhead to the loading of every file, or breaking file compatibility with Visual Studio (which DOES need the UTF8 header). :(.
For the next beta drop, coming Friday, i’ll add an (undocumented and not exposed-in-UI) plist setting called DontSaveUTF8Header. Set this to YES, and Fire will no longer save UTF8 headers for files.
Does that seem like a reasonable compromise until Apple fixes this?
I do recommend filling a bug with Apple. i did, and the more people do the better. Don’t mention Fire or Elements, that will just get it declassified as a third party corner case. Just log something like “Swift compiler cant handle files with 0xEF, 0xBB, 0xBF UTF-8 header marker”.
FTR, i had logged a radar for this ages ago, but i just now re-logged the issue in the open Swift bug tracker: https://bugs.swift.org/browse/SR-615.
Great, thanks, that does sound reasonable. Where abouts does the plist live?
running
defaults write com.remobjects.fire DontSaveUTF8Header YES
in Terminal should do the trick. You’ll need to restart Fire since the option is only checked for once, on startup.
And the Swift guys have already fixed and merged this. So this fix should be going into Swift 2.2.
Thanks for this, I can confirm its fixed the issue
The only problem I have now is that sometimes Fire changes all the whitespace in a file created by XCode, and makes a messy diff. Are there any settings for whitespace handling?
Not currently or anytime soon, no. Right now, Fire will always save with tab characters, for Swift and C#. It’s planned to make this more flexible in the future, but that going to involve some significant reworking for the editor, and is far off. Sorry.