When sorting lines using editor.action.sortLinesAscending ("Sort Lines Ascending" via the Command Palette) the lines are sorted in a very strange order when the comparison involves a symbol character.
I would expect that . (period) would be sorted before _ (underscore) because in ASCII, period is 46 and underscore is 95.
However, vscode uses localeCompare as its sorting method (see sortLinesCommand.ts:76), which results in underscore being sorted before period. See the repro steps below for an example.
I saw a previous issue regarding this (#15516) but it was closed because the ASCII ordering was in fact correct. In the case I've outlined below, the ordering is not correct.
I'm not sure what the correct solution would be but I think that for ASCII symbols, ASCII ordering should be obeyed. I do realise that "Sort Lines Ascending" is an ambiguous term - ascending according to what criteria? - so perhaps the command could be renamed to something more specific, or you could provide different default sorting options.
Steps to Reproduce:
a_b.txt
a_b_c.txt
````
2. Highlight the file contents.
3. Open the Command Palette and select "Sort Lines Ascending".
**Expected:**
The file is sorted in the following order:
a_b.txt
a_b_c.txt
**Actual:**
The file is sorted in the following order:
a_b_c.txt
a_b.txt
```
Does this issue occur when all extensions are disabled?: Yes
I don't have a strong opinion either way. However, the current usage of localeCompare is consistent to our using localeCompare in other places, like e.g. in the explorer:

Thanks for your response - interesting that the editor uses the same sort as the UI!
I use the sort function most often to sort lines in code, which usually contain only ASCII characters. The issue I (personally) have with the current vscode sort function is that when I pipe the file content into other utilities, those utilities expect lines to be in ASCII order.
Regarding the sorting of files in vscode's explorer, Windows explorer sorts the files as I would expect:

Sorting in ASCII order is beneficial as shorter filenames are placed before longer ones.
Since this is supposed to be a general sort & is also applied to UI elements, it's difficult to come up with a one-size-fits-all solution. Personally, I would introduce two settings:
sorting.method (or similar) which allows the options:ascii, for sorting code / lists of files.localeCompare, for sorting general text which may contain unicode characters, etc.sorting.caseSensitivity (or similar) which allows the options:caseInsensitive, values converted to lowercase before comparisoncaseSensitive, values compared without modificationPerhaps these settings could be separate from the sorting in the explorer, e.g. editor.sorting.method vs. explorer.sorting.method.
I'm currently sorting a very long YAML file in order for it to pass yamllint configured to enforce lexical sorting of keys. This issue is of interest to me because currently Code's idea of a lexical sort and yamllint's idea differ in the area of underscores:
After Code editor.action.sortLinesAscending:
---
underscore_underscore: second
underscore: first
yamllint output:
3:1 error wrong ordering of key "underscore" in mapping (key-ordering)
Yeah, I've run across this issue with the sort method as well.
One problem is that if you use unicode integer representations to sort, it will always be confusing. And you sort of have to use unicode to sort, since that's what we use in our editors nowadays.
For example: ' is greater than - according to VSCode.
So, the following would be in VSCode sort order:
gem 'graphql-example'
gem 'graphql'
And so would the following:
graphql-example
I believe this is because it uses the SMALL HYPHEN-MINUS character, and compares that to one of the single apostrophes, which have a higher integer representation.
I find it wrong that despite 99.999% of files in the world of coding use only ASCII in names and content, VSCode defaults to sorting in an unexpected way just so 0.001% of unicode cases could be satisfied. Unicode collation is for natural languages but programmer's editor/IDE more often than not deals with computer languages so is defaulting to localeCompare really justified?
I wonder if there can be some compromise sorting option that satisfies both needs. Similar to how natural order sorting puts file10 after file2 by splitting the string into spans of numbers and non-numbers. Or how Windows Explorer supports Unicode file names and yet sorts ASCII names in a usual way.
For someone looking to fix this in the Explorer, this config can help in many cases:
"explorer.sortOrder": "type"
Most helpful comment
Thanks for your response - interesting that the editor uses the same sort as the UI!
I use the sort function most often to sort lines in code, which usually contain only ASCII characters. The issue I (personally) have with the current vscode sort function is that when I pipe the file content into other utilities, those utilities expect lines to be in ASCII order.
Regarding the sorting of files in vscode's explorer, Windows explorer sorts the files as I would expect:
Sorting in ASCII order is beneficial as shorter filenames are placed before longer ones.
Since this is supposed to be a general sort & is also applied to UI elements, it's difficult to come up with a one-size-fits-all solution. Personally, I would introduce two settings:
sorting.method(or similar) which allows the options:ascii, for sorting code / lists of files.localeCompare, for sorting general text which may contain unicode characters, etc.sorting.caseSensitivity(or similar) which allows the options:caseInsensitive, values converted to lowercase before comparisoncaseSensitive, values compared without modificationPerhaps these settings could be separate from the sorting in the explorer, e.g.
editor.sorting.methodvs.explorer.sorting.method.