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

Previous Next

Full log

Message #128 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: Thu, 21 Aug 2014 17:41:22 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: michael_heerdegen <at> web.de,  18051 <at> debbugs.gnu.org
> Date: Thu, 21 Aug 2014 11:05:43 +0200
> 
> >> 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.
> >
> > That's what I had in mind, yes.
> 
> Finally, I came out with the appended patch. Comments appreciated.

Thanks.

I have 2 comments:

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

Previous Next

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