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

Previous Next

Full log

Message #149 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, 24 Aug 2014 18:18:24 +0200

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

>> > Or have a new optional argument in string-lessp etc., or introduce a
>> > new set of APIs which will accept a locale, and have string-lessp
>> > etc. call them with that argument nil.
>> 
>> An optional argument to string-lessp could be inconvenient. IMHO, the
>> most important use-case of string-lessp is being a PREDICATE of
>> sort. This does not support optional arguments.
>
> In those cases, we should add the same optional argument to the sort
> function.

That would be an option. But it would take decades, until all
appearences of sort have been adapted. That's why I'm in favor of a
global variable, which could be let-bounded.

But I don't oppose strongly to your proposal.

> I wonder what should this do if the new locale cannot be
> instantiated/installed.  As you wrote the code, it will silently use
> the current locale, but I wonder if that's TRT.

We could raise a warning. But if it is used in sort with a huge list of
strings, the user would be flooded with those warnings.

Maybe we could add a function, which would tell whether a given locale
value would have effect. The user could check then.

> Other than that, I think you should install this.

Done. Next days I'm on the road; the work still missing (extending Elisp
manual, writing ert tests, adapting ls-lisp) must be postponed to later
this week, or the week after.

Best regards, Michael.

Previous Next

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