Sort command does not use the same sorting scheme as Xcode

[barakwei]

Xcode supports sorting group by right clicking on the group and choosing "Sort by Name".
If you have a group with two files - A10.h and A2.h, for example, Xcode will put A2.h first.
xcodeproj sort command will do the simple alphabetic sort and put A10.h first.

The scheme used by Xcode is weird (try sorting A1 and A01, or even better A1B01, and A01B1). If someone accidentally knows what's the exact sorting scheme it will be great, but fixing the most simple case is sufficient.

[segiddins]

Pull requests improving the group sorting algorithm are very welcome!

[Coeur]

Oh, good case with ["A1B001", "A01B1"], it's not even the same order as the Finder.
It seems to me that, if two strings are naturally equal (like "A1B001 and "A01B1"):

• Xcode "Sort by name" logic is to do a second comparison where it sorts reverse-alphabetically (giving priority to values without leading zeros)
• Finder logic in this situation is to first sort by total length, then reverse-alphabetically

I'll try to implement the Xcode rule in ruby.

[Coeur]

OK, here is my ruby implementation:

[edit]

see pull request #677 now, and in particular file https://github.com/CocoaPods/Xcodeproj/blob/ca7b41deb38f43c14d066f62a55edcd53876cd07/lib/xcodeproj/project/object/helpers/sort_helper.rb

[Coeur]

@barakwei Algorithm fixed in the PR #677. Can you test it on your own files?

[Coeur]

@barakwei @segiddins Anything else to be solved, here?
In the mean time, I published my solution as a Stack Overflow answer with a few explanations on why it must be a lengthy piece of code: https://stackoverflow.com/questions/5480703/how-to-sort-an-alphanumeric-array-in-ruby/56000450#56000450

[barakwei]

Sorry for missing the discussion, I only noticed it now.
Here is a list of file names that you can use for testing:
File1.h
File2.h
File01.h
File001.h
File01aa.h
File001bb.h
File01bbb.h

In addition, I suggest adding files with "multiple extensions" like File.h, File.aa.h, File.bb.h and File.aa.bb.h.

Mixing between the two lists is also a good idea, there are probably many edge cases.

Good luck!

[Coeur]

@barakwei I mean: please look at my pull request #677: all those cases should pass already. Have a try from my branch https://github.com/Coeur/Xcodeproj/tree/xcode_sort.

[barakwei]

I've tried it. Unfortunately, it doesn't match Xcode's sorting.

I suggest to add them to the test of this class in any case. This is how Xcode sorts them (just like Finder, at least on my machine):

[
"File.aa.bb.h",
"File.aa.h",
"File.bb.h",
"File.h",
"File1.h",
"File01.h",
"File001.h",
"File01aa.h",
"File001bb.h",
"File01bbb.h",
"File2.h",
"File10.h",
]

Your sorting produces a different result:

File1.h
File01.h
File001.h
File01aa.h
File001bb.h
File01bbb.h
File2.h
File10.h
File.aa.bb.h
File.aa.h
File.bb.h
File.h

From what I understand, Finder uses -[NSString compare:options:range:locale:], which calls the same method in CFString. You can look for the source of this method online, but it's quite complex.
You could theoretically call the CFString method from ruby and have the desired effect, but that would work only on mac.

[Coeur]

Well, basically Xcode sorts a dot . before a digit like 0. That's the only diff and it's easily fixable.

[Coeur]

Actually, I found more cases failing with my original sorting: notably unicode characters, and that's a bit more tricky. Ah, if only the Xcode sort behavior was documented!

[edit]
I found a piece of doc for Finder at https://support.apple.com/kb/TA22935?locale=en_US

And some useful test cases and discussion at https://discussions.apple.com/thread/7602542

[barakwei]

From what I see, Xcode sorts like Finder. If you want to sort like finder you can call [NSString localizedStandardCompare:]. If we look at the source we can see which flags it uses.
You can see the sort is case insensitive and you can add that to the tests, and it also uses the current locale which makes things worse. In addition, it uses NSWidthInsensitiveSearch which affects Unicode characters which might explain what you see.

[Coeur]

I figured that. But solving the unicode sort may require activesupport, with either transliterate or mb_chars.normalize(:kd).

[Coeur]

And also, I just found that Xcode lists duplicate references at the end of everything else... that's yet another edge case that would need extra code to solve.

[Coeur]

In the mean time, the problem with the dots should now be solved in the PR. And for any new case that we may discover, it'll be worth checking if it's a regression compared to the plain sort algorithm or just some feature-request. As you said in your original post: "fixing the most simple case is sufficient".

[barakwei]

Looks like the latest code works on my use cases. Note that I provide the strings directly to the class and I do not separate the base name and extension, I guess the PR should do this as well.

Yes, I agree that the most important things are punctuations, numbers, spaces, and letters. If solving Unicode will be more complex, it can be done by demand as you say.
Also, the default behavior of the sort method doesn't have to change, you can provide a comparator and provide it to the sort method, which by default will not be used. That way existing users won't suffer any performance issues if there are any. It's up to the maintainers of the repo to decide.

Lastly, I want to thank you for taking the time to implement this feature. I'll surely use it.

[Coeur]

I've just found out that Xcode sorting is broken (unpredictable, weak, not strict) and I've opened a radar regarding it: http://www.openradar.me/radar?id=5012044621283328

So it's currently undesirable to follow exactly Xcode sorting on some edge cases (a strong strict total sorting is preferable, unless there is a big performance hit for that).