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

Previous Next

Package: emacs;

Reported by: michael_heerdegen <at> web.de

Date: Fri, 18 Jul 2014 06:24:01 UTC

Severity: wishlist

Found in version 24.3.92

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>,  Eli Zaretskii <eliz <at> gnu.org>
Cc: dmantipov <at> yandex.ru, 18051 <at> debbugs.gnu.org
Subject: bug#18051: [Emacs-diffs] trunk r117726: Add string collation.
Date: Wed, 27 Aug 2014 12:08:52 -0700
A couple more things.

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?

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.  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 way, string-collate-p would never have to 
inspect the environment itself, or to create or destroy a locale.




This bug report was last modified 10 years and 224 days ago.

Previous Next


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