bug#18051: 24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal function?

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: michael_heerdegen@web.de,  18051@debbugs.gnu.org, Paul Eggert 
> <eggert@cs.ucla.edu>
> Date: Sun, 20 Jul 2014 17:26:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Maybe we should expose glib's g_utf8_collate() on Lisp level.
> >
> > Are you sure this does the job?  Glib docs are minimal, and don't seem
> > to mention UTS#10.  E.g., if g_utf8_collate relies on the underlying
> > libc's strcoll, we are back at square one.
> 
> Well, I've checked the code of g_utf8_collate in glib 2.36. Shortly, it does
> 
> --8<---------------cut here---------------start------------->8---
> #ifdef HAVE_CARBON
> 
>   UCCompareTextDefault (kUCCollateStandardOptions,
>                         str1_utf16, len1, str2_utf16, len2,
>                         NULL, &retval);
> 
> #elif defined(__STDC_ISO_10646__)
> 
>   result = wcscoll ((wchar_t *)str1_norm, (wchar_t *)str2_norm);
> 
> #else /* !__STDC_ISO_10646__ */
> 
>   result = strcoll (str1_norm, str2_norm);
> 
> #endif
> --8<---------------cut here---------------end--------------->8---

As expected, it simply relies on the Standard C library's wcscoll
implementation.

> Likely, wcscoll implements only ISO 14651 (a subset of UCA these days),
> and likely wcscoll supports single byte characters only.

No, I expect wcscoll, at least in its glibc implementation, to support
the entire Unicode range.