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

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> Answering myself here: by reading the source of g_utf8_collate, it is
> clear that the implementation is elsewhere.  In particular, in any
> environment that defines __STDC_ISO_10646__ (as does glibc),
> g_utf8_collate simply calls wcscoll, after converting the UTF-8
> strings to wide-character strings.
>
> So I think a better alternative would be to base the implementation of
> this feature on the system libraries directly.  I think most modern
> platforms have the necessary facilities.

But OTOH, g_utf8_collate handles also other cases, like the #ifdef
HAVE_CARBON case.

So what, maybe it is sufficient to take over the implementation from
glib, indeed. There's not too much logic added there, and we would avoid
the glib dependency.

What I would really like to test are non-Latin coding points. I'm a noob
for such characters (glad to speak German, English and a little bit
Français); do you or somebody else has some test cases for
`gstring-lessp' or `gstring-equalp', which shall return different
results than `string-lessp' and `string-equal'?

Best regards, Michael.