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 <michael_heerdegen@web.de>,  18051@debbugs.gnu.org
> Date: Sun, 20 Jul 2014 13:44:07 +0200
> 
> Programs like `ls' honor the LC_COLLATE environment variable. Emacs
> shall do it as well.

That's clear, and is not the issue.  The issue is why (and how) does
having UTF-8 in the codeset part of the locale cause sorting to sort
as 'ls' does on GNU platforms.  And the answer is that the sorting
should implement UTS#10, which I'm not sure every platform does in its
standard C library.

> This shouldn't affect only directory listings, but could be used
> also for string searches.

That is a much larger job, and it's not clear how to do it best.
Emacs supports different languages in different buffers, and setting
and resetting LC_COLLATE for each buffer is not a good idea, IMO,
because thread-local locales are not well supported outside glibc
(AFAIK).

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

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

> I have no clear forecast on my time budget next weeks. If possible, I
> would play with this.

Thanks.