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@web.de,  18051@debbugs.gnu.org
> Date: Fri, 22 Aug 2014 16:23:34 +0200
> 
> >  . 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 everything in str_collate starting with the "Convert byte
stream to code pointers." comment (btw, I guess you meant "code
points" here) should be in a separate function, and the best place for
that function is sysdep.c.  At least on MS-Windows, both the part that
converts a Lisp string into wchar_t array, and the part that performs
a locale-sensitive string comparison, will be implemented differently.

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

Thanks.  (You didn't attach the new patch.)

Btw, I wonder whether we should have a way to pass the locale string
explicitly, instead of relying on $LC_COLLATE.

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

I'll defer to glibc experts on that.  My knowledge of 'newlocale'
facilities is limited to what I saw in Guile's i18n.c module.