-
Notifications
You must be signed in to change notification settings - Fork 29.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align explorer sorting with platform sorting #27759
Comments
I want sort order like GitHub repo. Please! |
Umm... I think it is the other way around, upper case first. Basically, just sorting using the ASCII value of each character. |
@dlech on Linux, at least, it depends on the chosen 'locale' and the environment variable If you consider to implement / support platform specific behaviour you may want to consider evaluating the locale setting on Linux, specifically LC_COLLATE (if set, otherwise fallback to the set local).
|
It's called shortlex, or lexiographic sort order. The only thing you need to tweak is the string length. If A is shorter than B then A is smaller than B. This is not going to be covered by any collation. An alternative to this is to introduce padding (padding of the sort so that the comparison is less) but I don't think it's reasonably to do that due to the extra garbage generated. To be more specific. For two strings @bpasero something like this: const a = one || "";
const b = other || "";
const minLen = Math.min(a.length, b.length);
const result = intlFileNameCollator
.getValue()
.collator.compare(a.substr(0, minLen), b.substr(0, minLen));
if (
result === 0
) {
if (a.length < b.length) {
return -1;
}
if (b.length < a.length) {
return +1;
}
return 0;
}
return result;
|
Shortlex orders primarily by length, the code presented implements a different ordering. The example:
as shortlex order would be:
Windows Explorer uses Natural Sort, because length is not sufficient for good order, as an example:
|
@egonelbre then I misunderstood the meaning of shortlex, I should have just said lexicographic. but the code does what it is supposed to do. that is, first sort up to X characters, then use the length as a discriminator. |
Why complicate this though. Lexicographic (not shortlex as I incorrect first called) it easy to implement and understand. This is not going to get done if we insist on extra work to align with something which is highly Windows Explorer specific. That should not be the high water mark here. |
It's not really Explorer specific, you can read more about it in https://blog.codinghorror.com/sorting-for-humans-natural-sort-order/. I mentioned it because your other issue showed that as an example. The reason you don't want to use lexicographic first is due to the last example.
Sorted lexicographically is:
|
@egonelbre as a programmer, I don't care. But as a user of Windows Explorer, I could see why adhering to the natural sort order would seem more natural. |
I tried making this: #75415 but was closed. There is currently no option to make the explorer sort native. and no-one writes 5, 10 we write 05,10, this is a fundamental fact. |
vs code sorts like this,
I'd rather it sort like this,
It is very jarring for me when vs code does not sort lexicographically. Almost every other tool I use sorts lexicographically. When vs code tries to be different, it just confuses me for a short moment. Repeatedly. And it adds up. Like @fenchu said, if I wanted to sort by numeric values, I'd zero-pad those numbers to the desired length. |
@bpasero I'm hoping you can advise and save me some time if this doesn't make sense or is unlikely to be accepted as a pull request. I'm considering creating a pull request that would add a new setting - I considered adding one or more options to the existing 'explorer.sortOrder': {
'type': 'string',
'enum': [SortOrder.Default, SortOrder.Mixed, SortOrder.FilesFirst, SortOrder.Type, SortOrder.Modified],
'default': SortOrder.Default,
'enumDescriptions': [
nls.localize('sortOrder.default', 'Files and folders are sorted by their names, in alphabetical order. Folders are displayed before files.'),
nls.localize('sortOrder.mixed', 'Files and folders are sorted by their names, in alphabetical order. Files are interwoven with folders.'),
nls.localize('sortOrder.filesFirst', 'Files and folders are sorted by their names, in alphabetical order. Files are displayed before folders.'),
nls.localize('sortOrder.type', 'Files and folders are sorted by their extensions, in alphabetical order. Folders are displayed before files.'),
nls.localize('sortOrder.modified', 'Files and folders are sorted by last modified date, in descending order. Folders are displayed before files.')
],
'description': nls.localize('sortOrder', "Controls sorting order of files and folders in the explorer.")
}, This change would only partially address this open issue, since it:
I think it would probably satisfy a lot of people though, and TBH I'm not sure that aligning with platform case sensitivity is the best option. For example, I noticed a number of comments on this and related issues were asking to align the file sort order with github, which always does a case sensitive sort. Anyway, by providing a setting, people can choose, and by defaulting to the current behavior nobody will be affected by the change unless they want to be. Also, if the future default behavior is changed, this setting will still be useful for people who want to override that default behavior. What do you think? Should I go ahead? If yes, is this the right issue to reference in the PR or should I create a separate issue that just links to this one? Thanks in advance! |
@leilapearson thanks for the offer. If that is not possible only then we can look into adding more settings. An alternative is to look to open this up to extensions and then extensions could control this and satisfy the 20 different sorting styles that users want. |
@isidorn thanks for the reply. That's why I asked before doing anything other than taking a look at the code. Opening this to extensions is an interesting option. At the same time, I would still think that offering control over whether the sort is case sensitive or not should be a core option and not require an extension. It isn't easy on some platforms to adjust the sort order - and having to figure out how to get your whole platform to sort case sensitive in order for VS Code to sort case sensitive seems a bit awkward? Especially if you primarily develop on one platform and only spend a bit of time developing on other platforms. Also, I find that programming on a platform is a different context than using a platform for office work. Having different sort orders apply to the different contexts often makes sense. For example, I tend to sort things by most recently modified when I'm working on documents and the like - so this is my default in file explorer and google docs. On the other hand, I don't want my code sorted by modification date and I'm happy with how things are sorted in my terminal - but unfortunately not so happy with how they are sorted in VS Code. I do agree that too many settings can be a bad thing, but I'm curious if you agree or not that a setting to control case sensitivity would make sense regardless? |
P.S. An example of how hard it can be to change the sort (collate) order on a platform is OSX - which doesn't expose any nice way to do that it seems: https://apple.stackexchange.com/questions/34054/case-insensitive-ls-sorting-in-mac-osx |
Any progress? |
@Sytten some sort order edge cases were addressed in #97200 and that change is available in vscode 1.46.0. See the PR for a detailed description. I also have an open PR #97272 - old now and sure to need an update - to add some additional lexicographic options to allow sorting in unicode order, locale order with uppercase first, or locale order with lowercase first. Which specific functionality were you hoping to see addressed? |
On MacOS the files are sorted case insensitive and I didnt find a way to sort them case sensitive (without affecting the order files/folders). |
PR #97272 adds the option to group files and folders by case, but that PR was submitted at a time when the reviewers weren't available and is out of date now. I'll take a look at resurrecting it. |
Just wanted to provide a couple of quick updates for anyone watching this issue.
|
These discussions are taking years and new sorting order proposals are coming up. I think most sort options are so niche, that I think it would be better for an extension to provide them instead of putting them in the core. Will there ever be an option to provide a custom sorting algorithm, or a way for an extension to add one? |
Thanks @leilapearson I will try it 👍 |
I agree it would be nice to be able to match the Windows file explorer order when desired (and probably by default when on Windows). It's complicated though and would require a function that can translate from unicode values to Windows Explorer sort order values - taking locale into account if necessary. I wasn't able to find such a function, and implementing one without actually having the code used in Windows Explorer seems like it would require a lot of time-consuming experimentation with different characters and locales. That said, vscode is made by Microsoft, so someone on the team may be able to use their contacts to get access to the relevant Windows Explorer function to make this easier :-) For my own possibly future reference - and maybe your interest - I've copied in a table showing one person's investigation The table comes from: https://superuser.com/questions/681322/windows-explorer-sorting-order-for-special-characters
You can see in the above that Windows order is Anyway, I'm open to helping out with this if someone can find me a function for reference :-) |
The main problem with not having these files sorted /nesting is having to maintain or support thousands of code and configuration files and folders, making adequate support using vscode difficult, as projects become more complex (bigger). An easy way to build this algorithm would be to use a "weight" which would be defined by the sum of the char code or a numbered alphabetic list of each letter of the word. This sum would define who goes up and down. The "weight" of directories would always be greater than the "weight" of files. |
vscode uses Javascript's // English locale
console.log('a'.localeCompare('aa', 'en')); // -1
console.log('a'.localeCompare('z', 'en')); // -1
console.log('aa'.localeCompare('z', 'en')); // -1
console.log('aaa'.localeCompare('z', 'en')); // -1
console.log('aa'.localeCompare('az', 'en')); // -1
console.log('å'.localeCompare('aa', 'en')); // -1
console.log('å'.localeCompare('z', 'en')); // -1
// Norwegian locale
console.log('a'.localeCompare('aa', 'no')); // -1
console.log('a'.localeCompare('z', 'no')); // -1
console.log('aa'.localeCompare('z', 'no')); // 1
console.log('aaa'.localeCompare('z', 'no')); // 1
console.log('aa'.localeCompare('az', 'no')); // 1
console.log('å'.localeCompare('aa', 'no')); // -1
console.log('å'.localeCompare('z', 'no')); // 1 Interestingly, I noticed that if you set your primary language to Norwegian and sort your sample files above by file type in Finder - instead of by name - you will see the same order that you get using localeCompare() and in vscode explorer. So even in Finder the behaviour is inconsistent. You would expect all files of the same type to sort by name, and for the order to be consistent with what you see when sorting directly by name, but that isn't the case (at least not on my system). I'll dig a bit further. |
That’s correct, aa is pronounced as å, wasn’t till 1917 we converted from aa to å. Denmark in 1948. Technically, it is correct. Aa is Å, and should be sorted with Å.
I just encountered this when I was directory named aad-pod-identity, and couldn’t understand why it ended up under Perhaps a setting in VS Code that lets me override which locale to sort with. Or just using the |
It looks like our file sorting in the explorer does not match platform beahviour in some cases.
Windows:
foo.ts
is sorted beforefoo_test.ts
but we sort it the other way aroundLinux:
foo.ts
is sorted beforefoo_test.ts
but we sort it the other way around[out, outb, outd, Outa, Outc]
are showing up as[out, OutA, outb, Outc, outd]
macOS:
We use a JavaScript
Collator
for the comparing here.Unfortunately I am not able to tweak the Collator options to bring me the desired result...
The text was updated successfully, but these errors were encountered: