Question

The following Objective-C code in XCode (which compiles)

NSString *someString = @"Lorem ipsum dolor.\nEget nisl nec risus";

after running Uncrustify becomes

NSString *someString = @"Lorem ipsum dolor.
Eget nisl nec risus";

which doesn't compile. Is there any way to avoid it changing line breaks embedded in an NString? I have been searching and reading the forums, as well as the cryptic Uncrustify config file and have been unable to find an answer.

By the way, I am using version 0.60 of Uncrustify.

Was it helpful?

Solution

Figured it out!

The problem is not with the config. It's with the AppleScript that is ran. On my system the AppleScript is at ~/Library/Services/Uncrustify_opened_Xcode_sources.workflow.

Basically reworked it a bit to be functional for the latest version of Uncrustify by modifying the generated document.wflow within the Uncrustify_opened_Xcode_sources.workflow application. Runs great for me, but might need adjustments. I only changed lines 99-105. I deleted the blockers.

https://github.com/heliumroe/Xcode-formatter/compare/octo-online:master...patch-1?quick_pull=1 for more details!

if (suffix = "m" or suffix = "h") then

tell application "Xcode" to (do shell script "'/usr/local/bin/uncrustify' -c " & "'" & uncrustifyConfigFilePath & "' -l OC --no-backup '" & currentDocumentPath & "'")

end if

end repeat
display dialog "DONE"
end tell

OTHER TIPS

Turns out it's a bug with Xcode-formatter, which does its magic in AppleScript. What we need is a wildcard or a regex in AppleScript to escape the \n linefeeds embedded in strings.

More info here:

https://github.com/octo-online/Xcode-formatter/issues/7

EDIT:

I found a workaround.

NSInteger newLineAsciiCode = 10;
NSString *newLineCharacter = [NSString stringWithFormat:@"%c", newLineAsciiCode];
NSString *someString = [NSString stringWithFormat:@"Lorem ipsum dolor.%@Eget nisl nec risus", newLineCharacter];
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top