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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: michael_heerdegen <at> web.de, eggert <at> cs.ucla.edu, 18051 <at> debbugs.gnu.org
Subject: bug#18051: 24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal function?
Date: Sun, 20 Jul 2014 19:16:57 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: michael_heerdegen <at> web.de,  18051 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 20 Jul 2014 17:26:04 +0200
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.