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

Previous Next

Full log

Message #134 received at 18051 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: michael_heerdegen <at> web.de, 18051 <at> debbugs.gnu.org
Subject: Re: bug#18051: 24.3.92; ls-lisp: Sorting;
 make ls-lisp-string-lessp a normal function?
Date: Sat, 23 Aug 2014 12:05:51 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: michael_heerdegen <at> web.de,  18051 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.