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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>  . I suggest to factor out the part that converts to wchar_t, sets up
>    the locale, and calls strcoll.  The code you wrote makes certain
>    assumptions about 'setlocale', and also about the wchar_t
>    representation.  Factoring those system-dependent parts out will
>    minimize the number of #ifdef's needed to provide such features for
>    other platforms.

I see. But I don't know how to factor out. Shall I move str_collate to
another file? Or to a new file? Something else?

>  . I think glibc has a 'newlocale' API that is better suited to this
>    kind of jobs.  In particular, 'setlocale' changes the locale of the
>    entire program, which is bad news for other threads that might be
>    using some locale-aware functions while the main thread calls
>    string-collate-lessp.  (We have more than 1 thread in Emacs built
>    with GTK, for example, and who knows what those threads might be
>    doing?)

OK, done.

I have added also configure checks HAVE_NEWLOCALE, HAVE_USELOCALE and
HAVE_FREELOCALE for the respective glibc functions. I don't know whether
it is overengineering, and whether I could simply apply the existing
HAVE_SETLOCALE check. I believe all these functions do exist in parallel
in locale.h, don't they?

Best regards, Michael.