explorer.sortOrder default doesn't work well for hashes

[Tyriar]

With this folder https://github.com/lunapaint/imagetestsuite/tree/main/png, it starts off alphabetical but gives up shortly after. It looks like the it's sorting by the number first such that 3, 20, 100 appear in the "correct" order. I suggest making one of the following changes:

• Only use that rule when the file name excluding the extension is a number (not sure what cases are being covered)
• Add a setting for actual alphabetical sorting
• My preference: Sort alphabetical if the file name looks like a hash (/[0-9a-f]{7,32}/)

Have been hitting this a decent amount recently, instead of a quick find via visual check I need to type out the first part of the hash to filter the explorer.

[JacksonKearl]

I've found "explorer.sortOrderLexicographicOptions": "unicode" good for this:

Does that work for you?

[Tyriar]

If I understand that setting right, it would not treat a and A the same. So no, this wouldn't work as I don't want to keep switching my explorer's sorting options depending on what I'm doing.

[JacksonKearl]

We're using Intl.Collator's for a lot of this:

vscode/src/vs/workbench/contrib/files/browser/views/explorerViewer.ts

Lines 684 to 701 in 3f1f126

	switch (lexicographicOptions) {
	case 'upper':
	compareFileNames = compareFileNamesUpper;
	compareFileExtensions = compareFileExtensionsUpper;
	break;
	case 'lower':
	compareFileNames = compareFileNamesLower;
	compareFileExtensions = compareFileExtensionsLower;
	break;
	case 'unicode':
	compareFileNames = compareFileNamesUnicode;
	compareFileExtensions = compareFileExtensionsUnicode;
	break;
	default:
	// 'default'
	compareFileNames = compareFileNamesDefault;
	compareFileExtensions = compareFileExtensionsDefault;
	}

, but unicode is just the built in < operator... not sure if there's a Collator config for what you want, I wouldn't want to hardcode something that only works in properly in english. It may just be a matter of not passing numeric: true, though that would break a.1.txt, a.2.txt, ... a.10.txt.

[JacksonKearl]

Probably covered by #27286 / #27759 at some point.

[Tyriar]

It's similar to #27759 and is called out in one of the comments (#27759 (comment)). But I think this issue is distinct as this is specifically related to the special number handling at the beginning of the file, not like the primary case that's called out there:

a file foo.ts is sorted before foo_test.ts but we sort it the other way around

#27759 is more about how files with the same prefix are sorted relative to each other.

[JacksonKearl]

I could see adding a case-insensitive unicode variant. IMO this would be preferable to designing something custom for numeric prefixes.

Also worth exploring whether a non-numeric collator would help here.

[Tyriar]

@JacksonKearl not sure I want a case insensitive unicode variant though, I want the best of both worlds; the sorting today with fixes described in #27759 and hashes sorted logically. Not familiar with the code but it seems achievable.