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.
