emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test-org-table/sort-lines: Failing test on macOS


From: Max Nikulin
Subject: Re: test-org-table/sort-lines: Failing test on macOS
Date: Wed, 12 Oct 2022 23:09:59 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

On 11/10/2022 05:25, Rudolf Adamkovič wrote:
(string-collate-lessp "a" "b" "C" t) ; t
..
(string-collate-lessp "a" "b" "C" nil) ; t
..

So basic sanity tests passed.

(string-collate-lessp "a" "B" "C" nil)  ; => nil
(string-collate-lessp "a" "B" "POSIX" nil) ; nil

is expected behavior as well. What I do not like is

> (string-collate-lessp "a" "B" "C" t)  ; => nil
Actually you wrote
[FYI: If I replace nil with t, the procedure returns nil too.]
From my point of view it is a reason to file an Emacs bug because I get

    (string-collate-lessp "a" "B" "C" t) ; => t

It seems case folding works strange for comparison because when case is the same "a" < "b" as expected:

(string-collate-lessp "a" "b" "C" t) ; t
(string-collate-lessp "A" "B" "C" t) ; t
(string-collate-lessp "a" "b" "C" nil) ; t
(string-collate-lessp "A" "B" "C" nil) ; t

May it happen that IGNORE-CASE argument is ignored in your case? I believe, it is improbable that C locale is not generated, so case fold rules are undefined

    locale -a | grep C

Another your strange result is

$ locale -a | grep en_US
en_US.US-ASCII
en_US.UTF-8
..
so en_US locale is defined but collation rules are different from glibc
printf 'a\nB\n' | LC_COLLATE=en_US.UTF-8 sort
B
a

I have no idea if sort and Emacs use the same libc and the same locale definitions. I am unaware which way it is organized in MacOS.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]