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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18051 <at> debbugs.gnu.org, dmantipov <at> yandex.ru, michael.albinus <at> gmx.de
Subject: Re: bug#18051: [Emacs-diffs] trunk r117726: Add string collation.
Date: Wed, 27 Aug 2014 22:54:54 +0300

> Date: Wed, 27 Aug 2014 12:08:52 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: dmantipov <at> yandex.ru, 18051 <at> debbugs.gnu.org
> 
> First, the current algorithm looks only at LC_COLLATE, but the usual 
> approach is to default LC_COLLATE to LANG if LC_COLLATE isn't set, and 
> to have LC_ALL override LC_COLLATE.  Shouldn't Emacs take a similar 
> approach, for compatibility?

I think we agreed to have a variable that holds the non-default locale
as a Lisp string.  LANG and LC_COLLATE will then be used internally by
newlocale and/or wcscoll_t, as users expect.  I don't think it's
appropriate for a primitive to take arguments from environment
variables, certainly not those on process-environment.  If some Lisp
application would want to do that, let them.

> More generally, it strikes me that string-collate-lessp will be quite 
> slow due to the overhead of looking up the locale environment string and 
> creating and destroying a locale for each string comparison.

The lookup will no longer be relevant, when we switch to a variable.

As for creating and destroying the locale, I guess you are right.

> Instead, shouldn't Emacs should have a locale object that the Emacs
> Lisp programmer can create, an object that encapsulates the low
> level locale_t object, and which can be passed as an optional
> argument to string-collate-lessp?

That's what Guile does.  But it will complicate using these functions
in sorting routines.  Perhaps binding a variable to the object will
do.

Alternatively, a simple one-slot cache internal to string_collate will
probably remove most of the overhead.  (You will see that
w32_compare_strings already employs a similar cache.)

Previous Next

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