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

[Michael Albinus]

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

Likely, wcscoll implements only ISO 14651 (a subset of UCA these days),
and likely wcscoll supports single byte characters only. I will run some
tests next days.

An alternative would be libicu, which seems to implement UCA
completely. I have no idea whether there are licensing issues when
linking with Emacs, 'tho.

Maybe Paul knows better which library to use? I've seen in GNU grep's
Changelogs, that wcscoll was used, but removed last year. I haven't
checked (yet) what is the replacement.

>> On systems without glib, we might emulate it partially. Packages
>> like ls-lisp could use it then for sorting.
>
> I think we need our own implementation in any case.  If nothing else,
> that would solve the issue of encoding strings into UTF-8 before
> calling external C functions.

Yep. But given the complexity of UCA, we will start slowly with a subset
of the algorithm only. This and performance considerations will still
demand for a native C library, if available.

Best regards, Michael.