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

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sun, 17 Aug 2014 20:46:11 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Answering myself here: by reading the source of g_utf8_collate, it is
> clear that the implementation is elsewhere.  In particular, in any
> environment that defines __STDC_ISO_10646__ (as does glibc),
> g_utf8_collate simply calls wcscoll, after converting the UTF-8
> strings to wide-character strings.
>
> So I think a better alternative would be to base the implementation of
> this feature on the system libraries directly.  I think most modern
> platforms have the necessary facilities.

But OTOH, g_utf8_collate handles also other cases, like the #ifdef
HAVE_CARBON case.

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.

What I would really like to test are non-Latin coding points. I'm a noob
for such characters (glad to speak German, English and a little bit
Français); do you or somebody else has some test cases for
`gstring-lessp' or `gstring-equalp', which shall return different
results than `string-lessp' and `string-equal'?

Best regards, Michael.

Previous Next

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