[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexis
Subject: bug#20316: 24.5; `string-lessp' doesn't respect value of LC_COLLATE
Date: Wed, 15 Apr 2015 09:55:22 +1000

Eli Zaretskii <address@hidden> 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:


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 ....


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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]