Sorting order for UTF8 ignores "-"

[jporkkahtc]

If I have a buffer with

Code: [Select]

-band
begin
-bnotit sorts differently if it is ACP vs UTF-8
With UTF-8, apparently the leading "-" is ignored.

ACP Ordering:

Code: [Select]

-band
-bnot
begin
UTF8 Ordering

Code: [Select]

-band
begin
-bnot


[Clark]

Interesting. works for a line selection. Also works for the sort-buffer command. Odd when you use a column selection. We will look into this.

not sure how long this has been this way. v25 is the same.

[Clark]

I'm not sure this is a bug. SlickEdit is calling the Win32 CompareStringW function which sorts this way. Make a directory and put the following file names in the new directory:

a
b
-c

Notice that the windows file explorer displays the sort order the same as SlickEdit.

[Clark]

Decided not to use CompareStringsW.  This win32 function seems to always be case insentive which is definitely a bug. Also, SlickEdit file explorer like dialogs already don't use this function for Unicode. Might as well have all platforms do the same thing.

Thanks for noticing this weirdness.

[jporkkahtc]

Cool.

So, why would you be using a win32 function for sorting?
Wouldn't you want some portable function?

FWIW, I was just using gui-sort, and sorting the whole buffer.

[Clark]

My original testing was flawed. All edit window sort commands were off.

Doing full featured Unicode string operations is very complicated. On non-windows platforms we just blow off all the complicated stuff.