Folders in the Explorer with . are not sorted in alphabetical order

[strayfatty]

Issue Type: Bug

When using folder names with a '.' the folders are not listed in alphabetical order.

In the example 'a.a.a' is sorted behind 'a.c'.

Perhaps caused by #97200. Which, if I understand it correctly, sorts folder names as if they were file names with an extension.

Version 1.46.0

Version 1.45.2

VS Code version: Code 1.46.0 (a5d1cc2, 2020-06-10T09:03:20.462Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item	Value
CPUs	Intel(R) Core(TM) i9-9900KS CPU @ 4.00GHz (16 x 4008)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.92GB (20.11GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (8)

Extension	Author (truncated)	Version
Bookmarks	ale	11.0.0
vscode-todo-plus	fab	4.14.1
rest-client	hum	0.23.2
vsliveshare	ms-	1.0.1847
debugger-for-chrome	msj	4.12.3
vscode-streamdeck	nic	3.1.5
typescript-hero	rbb	3.0.0
vscode-table-formatter	shu	1.2.1

[gjsjohnmurray]

@isidorn you handled the PR that may have caused this.

My Windows Explorer orders them like this (I added b.txt for clarity):

1.46.0 Explorer:

[isidorn]

I acknowledge the issue. And yes that was the idea behind the PR.
I see how this can be unexpected so we might need to introduce a setting to control this.

[Tylerian]

@isidorn I love the idea behind the PR of arranging together all elements with same name and different extension, and would be a pitty if you decide to roll it back.

However, it behaves wrong in some cases.

Example

Perhaps a hotfix would be switching the ordering priority of ' '-' and '.' so all items with '-' in their name groups after those with '.'

wdyt?

[isidorn]

@leilapearson fyi as the author of the PR.

[leilapearson]

By way of explanation, filename sort now compares the name part of the filenames first and then compares the extensions only if the names are different.

The extension is the part after the final dot in the name - not the part after the first dot you come to. For example, foo.bar.js is considered to be a js file, not a bar.js file.

In the hero examples, the file extensions are tsx and sccs, not tsx and .module.scss. The file names (without extensions) are hero, hero-carousel, hero-carousel.module, and hero.module.

So, looked at this way, the sort order makes sense, but obviously it isn't what everyone is expecting.

How to resolve this?

Well, not long after submitting this PR, I also submitted a separate PR #97272 that is awaiting review. If accepted - that PR provides the option of using unicode for the sort order on the whole filename without distinguishing between the name and the extension:

Here are the results using the unicode option:

And:

I still don't love the way the hero files sort, but this is the way you'll see the files sort anywhere that does a simple unicode sort, which is the most common way to sort files I believe.

[leilapearson]

To throw in an extra complication, here's the hero example again but with file names that include an underscore instead of a '-'. Underscore sorts after '.' in unicode order but before '.' in locale-order.

Unicode:

Default locale order with names compared before extensions:

Mac terminal (same as unicode):

Mac file explorer:

It looks like Mac file explorer is not separating names and extensions before sorting in locale order - thus the different result.

@gjsjohnmurray could you maybe check what windows explorer shows in this case too? I don't have a windows machine handy and I'm not sure it behaves the same as a Mac.

At this point I'm thinking the default sort should probably emulate the file explorer results - but I'm not sure if all file explorers are the same or not...

[leilapearson]

BTW, the reason for comparing name before extension was so that hero.tsx would sort before hero_carousel.tsx and hero-carousel.tsx - which makes sense.

Unfortunately there doesn't seem to be one good option that will give everyone what they expect in all circumstances.

I think that the best we can do is to provide options to let people see whatever they see most commonly in other file explorers.

[leilapearson]

Oops. Just reread the first comment in this report and realized it is specifically referring to the folder names. @strayfatty is correct that folder names should not be treated like file names with extensions. I can create a new PR that corrects that.

[leilapearson]

Okay... so I made a quick change so that I don't bother comparing names separately from extensions at all for both files and folders.

This results in the following, which is consistent with Mac file explorer order:

vscode:

osx file explorer:

vscode:

osx file explorer:

@isidorn and others, can you comment on whether or not this is how you would like the default to behave?

[leilapearson]

For consistency with the above "sort by full filename" behavior, I think it probably also makes sense to change the way sort by type behaves, so I created a new local implementation that first groups by type, and then sorts by full filename, instead of looking at just the name part.

This is different from both the 1.45 behavior and the 1.46 behavior. It seemed weird to wind up with different sort orders for files that all have the same type when switching between "type" and "default" (e.g. 'a.a.txt' before 'a.txt' in one case - and the opposite in the other).

My new local version:

vscode 1.46.0:

vscode 1.45.0:

My new local version:

vscode 1.46.0:

vscode 1.45.0:

[gjsjohnmurray]

@gjsjohnmurray could you maybe check what windows explorer shows in this case too? I don't have a windows machine handy and I'm not sure it behaves the same as a Mac.

@leilapearson here is what Windows Explorer gives me:

[leilapearson]

Thanks @gjsjohnmurray

Hmm... It looks like the character sort order is . _ - in your case... whereas in my case the sort order is _ - .

The order you are seeing also doesn't match unicode order which is - . _

Maybe your results are due to your locale? I tried a number of different locales on my system and didn't find one that shows the results that you are seeing though. Can you share what system locale are you using so that I can check?

If it isn't caused by a locale difference, I guess it is possible the code on windows is doing something special with the dot character – for example temporarily replacing it with a space character before doing a sort since a space character will sort first. If so I'm not sure that we should emulate that behavior if other systems don't do the same.

Regardless of the order of the punctuation characters, your results do confirm that the sort order on Windows does not treat the extension separately from the name portion of the full filename, so I think it makes sense to go ahead and change the behavior in vscode to match. It actually simplifies the code which is a nice bonus.

[gjsjohnmurray]

Can you share what system locale are you using so that I can check?

@leilapearson it is set to English (United Kingdom)

[leilapearson]

Thanks again @gjsjohnmurray. It isn't the locale then. I still get _-. for the sort order if I switch to English (UK) on my Mac. I guess the string comparison function used in Windows Explorer prioritizes the dot character differently than Javascript localeCompare() does.

@isidorn any thoughts on what to do about this? Is it okay to sort files in localeCompare() order on all platforms, even if that is different than what Windows Explorer does? Or should we try to compensate?

If we should compensate, what would control whether or not we prioritize the dot character before the other characters?

1. Always prioritize the . first?
2. Provide an option to prioritize the . first?
3. Prioritize the . first only on Windows? (I assume
4. Platform detection plus an option to override if desired?

Personally I'd like to keep things simple and either:

1. sort in localeCompare() order like the Mac file explorer does - OR
2. always prioritize the . first.

The second option is a bit more code, but it does produce somewhat nicer results when sorting files. For example,aggregate.go will sort before aggregate_root.go that way.

On the other hand, I'm not sure if Mac users will like it that way or not.

Personally I'm fine either way.

@strayfatty and @gjsjohnmurray your thoughts would be appreciated too.

[isidorn]

@leilapearson I have to be honest I did not have time to read through the whole thread.
However for now it is fine to sort files in localeCompare() order on all platforms even if that differs from Windows Explroer. So let's keep this bheavior for now imho

[kanlukasz]

It's great to see that files are now sorted with a separate sorting for files with the extension only (.dot).
It's very cool! Great job 👍

[leilapearson]

@isidorn this bug report is still bothering me and I'd love to fix it - but I agree we should be cautious as it seems no one option can please everyone. Note that the current sort order matches neither Windows Explorer nor OSX File Explorer.

Still I think we should consider one of the following:

(a) Change it so folders do not sort by name then extension. After all, folders don't really have extensions. This would require creating a different compare function to use for folders (compareFolderNames?). OR
(b) Change it so that neither folders nor files sort by name then extension. This would use the same compare function for both folders and files, and would also match how OSX sorts things.

Any further thoughts?

[s4m0r4m4]

Just one user's viewpoint: sort files by name comparing characters from left to right until you hit a character pair that doesn't match.

Right now that's not happening for angular component vs. spec files, which can drive a guy crazy (I would expect to see .spec.ts after .ts):

[leilapearson]

Thanks for the feedback @s4m0r4m4 . I'm leaning that way myself. This would be option (b) above.

[leilapearson]

Just a note not to expect any changes on this until at least August - and then of course only if we can agree on a suitable approach. I'm told that key reviewers are out of the office until the end of this month. Feedback still appreciated in the meantime though! :-)

[MarkBoote]

Switching between explorer, dir & ls on windows & linux, which sort as *.spec.ts, *.ts, really makes my head hurt looking at vscode.
Tried & failed to find a single tool that orders files in the way vscode currently does.

[drasticp]

@leilapearson A few comments ago you said a change was made. I assume you meant to local code and not a submitted pull request? I'm just trying to catch up so I can keep an eye on the resolution. In my opinion the original change that was made for added convenience in viewing files created what is a pretty serious workflow issue with folders.

I'm working on a solution with around 60 projects. In this solution, Foo.Bar.Tests is nowhere near the Foo.Bar project. In terms of priority I would vote for the smallest change to straighten out the folder order. From what I read above, it seems like that may be your option (a).

I hope the feedback is valuable.

[leilapearson]

Hi @drasticp. Yes, I only made the change locally - and the change I made implements option (b) which is actually the simpler option.

As mentioned, some key maintainers are away this month - and a PR won't be merged without their approval - so I'll submit the PR sometime before the end of this month so it can be considered in early August when they're back.

I'll be sure to mention this issue in the PR so you can monitor that once it is created.

[isidorn]

Fixed via #104528 thanks to @leilapearson 👏