bug#20316: 24.5; `string-lessp' doesn't respect value of LC_COLLATE

[Alexis <flexibeast@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> I think we use "lexicographic" for lack of a more accurate word. 
> We could use something like "code point (binary) order", but 
> would that be clear enough to be useful?

i would certainly find that more useful overall, as i think it's 
less ambiguous (to me) than 'lexicographic order' in this 
context. i assume it's "code point [according to the overall 
encoding of the relevant buffer]"? And given your earlier point, 
i'm guessing it would also be useful to say something along the 
lines of "If the data being sorted contains multiple encodings, 
all bets are off"? (Which is relevant in the `org-vcard' case of 
people possibly trying to sort contacts whose names are based in a 
variety of locales.)

> Note that we are not alone in this; at least this page:
>
>   http://en.cppreference.com/w/cpp/string/byte/strcoll
>
> says that the C function 'strcmp' does a "lexicographical 
> comparison".  So do a few other similar pages; google for 
> "difference between strcmp and strcoll".

Well, that to me feels like continued holdover from the C+ASCII 
(or at best Latin-1) 'byte == character' mindset ....

>> A,B,C,Č,Ć,D,Dž,Đ,..S,Š,..Z,Ž
>
> That's "collation order" in action, note that the diacritic 
> order is applied _after_ the alphabetic order of the base 
> characters.  That's what string-collate-lessp does.

*nod* That's why my first thoughts about this issue went to 
collation settings; given that (it seems to me) Emacs has a far 
better handle on i18n and m17n issues than most software, i 
assumed that sorting-by-collation-order would already be available 
in 24.x. However, given what you've said, i've now got a better 
understanding of why implementing this is not straightforward.

Thanks for taking the time to explain all this! 


Alexis.