Eli Zaretskii writes: >> > In the strict order of Unicode codepoints? Use compare-strings. >> >> Thanks for the clarification. >> After further considerations, it looks like we should still use >> `string-collate-lessp' on Org side as it yields expected results if libc >> properly implements the collation. > > Is the feature that uses it intended to be used only on glibc platforms > (which basically means GNU/Linux)? If not, I'm surprised that you arrived > at this conclusion. It is the 180 deg opposite of what I think you should > have decided. > > Once again: locale-specific collation order is inherently unpredictable in > its results, and should only be used when the locale-specific order is a > _must_, like when sorting people's names for a telephone directory. We use string collation for 1. Sorting bibliographies 2. Sorting lists 3. Sorting table lines 4. Sorting tags 5. Sorting headings 6. Sorting entries in agendas 7. As a criterion for agenda/tag filtering when comparison operator is used on string property values (11.3.3 Matching tags and properties) 1-6 should follow the locale. I think we had a bug report in the past where a user got confusing about list sorting being confusing for the user language conventions. 7 is more debatable. >> Maybe change >> >> If your system does not support a locale environment, this function >> behaves like `string-lessp'. >> >> to >> >> Some operating systems do not implement correct collation (in specific >> locale environments or at all). Then, this functions falls back to >> case-sensitive `string-lessp' and IGNORE-CASE argument is ignored. > > Fine with me. See the attached patch.