From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20316: 24.5; `string-lessp' doesn't respect value of LC_COLLATE Date: Mon, 13 Apr 2015 17:48:55 +0300 Message-ID: <83twwkccdk.fsf@gnu.org> References: <87twwk61re.fsf@gmail.com> <87h9sk5z6a.fsf@gmx.de> <87pp785y21.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1428936565 17067 80.91.229.3 (13 Apr 2015 14:49:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2015 14:49:25 +0000 (UTC) Cc: michael.albinus@gmx.de, 20316@debbugs.gnu.org To: Alexis Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 13 16:49:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yhffm-00085o-9x for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Apr 2015 16:49:14 +0200 Original-Received: from localhost ([::1]:52233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yhffl-000772-JC for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Apr 2015 10:49:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yhffe-0006zg-Vp for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2015 10:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yhffa-0006tR-Ql for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2015 10:49:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yhffa-0006tM-Ml for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2015 10:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yhffa-0004i7-6H for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2015 10:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2015 14:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20316 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20316-submit@debbugs.gnu.org id=B20316.142893653718096 (code B ref 20316); Mon, 13 Apr 2015 14:49:02 +0000 Original-Received: (at 20316) by debbugs.gnu.org; 13 Apr 2015 14:48:57 +0000 Original-Received: from localhost ([127.0.0.1]:55118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YhffU-0004ho-MS for submit@debbugs.gnu.org; Mon, 13 Apr 2015 10:48:57 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:45821) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YhffR-0004hZ-9d for 20316@debbugs.gnu.org; Mon, 13 Apr 2015 10:48:54 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NMR00K0029Q7200@mtaout28.012.net.il> for 20316@debbugs.gnu.org; Mon, 13 Apr 2015 17:47:30 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMR00BNW2F66V90@mtaout28.012.net.il>; Mon, 13 Apr 2015 17:47:30 +0300 (IDT) In-reply-to: <87pp785y21.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101480 Archived-At: > From: Alexis > Date: Mon, 13 Apr 2015 16:42:30 +1000 > Cc: michael.albinus@gmx.de > > (getenv "LC_COLLATE") => "hr_HR.UTF-8" > (string-lessp "Æ" "D") => nil > (string-lessp "Ð" "S") => nil > (string-lessp "©" "Z") => nil > > `string-lessp' is not design to respect collation order. The docstring speaks about lexicographoc order. > > i'm sorry, i don't follow this. Yes, the docstring talks about lexicographic order. But i think it's reasonable for users to expect Emacs' built-in sort functionality (e.g. `sort-lines') to respect their current locale such that lexicographic order and collation order are treated as basically synonymous. Unless there's an important distinction between the two in this context that i'm missing? Emacs is a multi-lingual editor, and it isn't clear how to apply locale-specific settings, including collation, to text that can potentially include many scripts. E.g., a locale could specify a codeset that doesn't cover characters outside of a particular script, which will produce undefined results if you try using system sorting routines with characters outside of that single script. Also, using locale-specific sorting would produce different results not only in different locales, but also on different platforms in the same locale, because the implementation of locale collation order differs from platform to platform and from one C library to another. Please also note that locale-sensitive collation order could mean more than just order of characters. E.g., it could specify that punctuation characters or differences in accents should be ignored. So by default, Emacs sorts disregarding locale-specific ordering, basically using the Unicode codepoints of the characters to order them. > In this specific case, a user of a package i maintain was surprised when `org-sort' didn't sort their Croatian-language Org entries properly. Under the hood, `org-sort' uses `string-lessp'. Is the bottom line that they'll have to wait until at least 25.1 before Org could add conditional code to use `string-collate-lessp', to at least DTRT for users of >25.0? You could use the external 'sort' utility in the meantime, if it supports locale-dependent ordering. Once again: the results will be not 100% deterministic, even for the same locale, so your users should "caveat emptor". May I ask what does that package of yours do that it needs locale-dependent sorting?