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

[Max Nikulin <manikulin@gmail.com>]

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.