Michael Brand writes:
> The attached patches implement this suggestion and are applicable on
> bugfix and main. Tested with Emacs 29.4 of Homebrew on macOS. Please
> review and if someone can test the final version also on Linux and
> Windows I suggest to apply on bugfix.
Thanks!
Applied, onto b
On Mon, Jan 6, 2025 at 9:49 PM Michael Brand wrote:
> My patch _neutralizes_ the ignore case behavior of ~string-collate-lessp~.
The attached patches implement this suggestion and are applicable on
bugfix and main. Tested with Emacs 29.4 of Homebrew on macOS. Please
review and if someone can test
On Mon, Jan 6, 2025 at 7:38 PM Ihor Radchenko wrote:
> There was a transient problem on main. Now, make test should run.
Now I see, fixed a few minutes before my post, thank you. This reveals
that the test failure discussed here is the same on main as on bugfix.
In the following I will use the
Michael Brand writes:
> For this specific subject I can not see a follow up in this thread, or
> an implementation on the branches bugfix or main. And the complaint of
> the OP about the failing test is still valid on bugfix (on main ~make
> test~ aborted before with "void-variable (file)" on "(d
Hi all
On Tue, Nov 22, 2022 at 2:14 AM Ihor Radchenko wrote:
>
> Max Nikulin writes:
>
> >>> Concerning the test, I would split the current testcase into 2 parts
> >>> depending on WITH-CASE argument, check if caseless collation is
> >>> available and skip the related test otherwise.
> >>
> >> H
Ihor Radchenko writes:
>> The only additional consideration is that compare function should be
>> configurable. If a user access same files from Linux and macOS then it
>> may be really annoying to get different order of entries in agenda. For
>> most of Linux users it is better to use more sm
Max Nikulin writes:
>> This sounds like something to be adapted to Emacs upstream.
>> I suggested to change `string-collate-lessp' fallback behaviour to use
>> `downcase' when IGNORE-CASE is non-nil. See my last message in
>> bug#59275.
>
> I do not share Eli's position "all or nothing". I prefer
On 26/11/2022 09:05, Ihor Radchenko wrote:
Max Nikulin writes:
This sounds like something to be adapted to Emacs upstream.
I suggested to change `string-collate-lessp' fallback behaviour to use
`downcase' when IGNORE-CASE is non-nil. See my last message in
bug#59275.
I do not share Eli's posit
Max Nikulin writes:
>> However, I feel a bit lost about what to do on Org side.
>> We can put a disclaimer in the manual and all that, but it still feels
>> too complex.
>
> My current suggestion is to provide a fallback to `downcase' in the code
> and to explain in the manual that runtime envir
On 23/11/2022 22:27, Max Nikulin wrote:
(setq lst '("semana" "señor" "sepia"))
(sort lst #'string-lessp) ; => ("semana" "sepia" "señor")
(sort lst #'string-collate-lessp) ; => ("semana" "señor" "sepia")
On 23/11/2022 17:37, Ihor Radchenko wrote:
Eli even argued that `string-collate-les
On 23/11/2022 17:37, Ihor Radchenko wrote:
Max Nikulin writes:
Strings to sort are passed either through `identity' or
through `downcase'.
Thanks for the pointer.
Now, I am getting more confused though.
Do we even need to use `string-collate-lessp' then?
I think we do because sort result is
Max Nikulin writes:
> On 22/11/2022 08:14, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
2. `org-sort-list'
5. `org-sort-entries'
>>> `downcase' is used, not proper case folding, so a potential issue
>>
>> `downcase' is used to determine user input about sorting type.
>> Not for sor
On 22/11/2022 08:14, Ihor Radchenko wrote:
Max Nikulin writes:
2. `org-sort-list'
5. `org-sort-entries'
`downcase' is used, not proper case folding, so a potential issue
`downcase' is used to determine user input about sorting type.
Not for sorting itself.
See case-func variable. Its initi
Max Nikulin writes:
>> 2. `org-sort-list'
>> 5. `org-sort-entries'
> `downcase' is used, not proper case folding, so a potential issue
`downcase' is used to determine user input about sorting type.
Not for sorting itself.
>> 4. `org-set-tags' (tag order), when `org-tags-sort-function' is set to
On 21/11/2022 10:15, Ihor Radchenko wrote:
Max Nikulin writes:
However, I am not sure if ignoring locale is something we really want.
WDYT?
I think we should keep `string-collate-lessp' in the
`org-table-sort-lines' implementation. Users expect sorting accordingly
to their locales. However it
Max Nikulin writes:
>> However, I am not sure if ignoring locale is something we really want.
>> WDYT?
>
> I think we should keep `string-collate-lessp' in the
> `org-table-sort-lines' implementation. Users expect sorting accordingly
> to their locales. However it is better to add a warning to
On 20/11/2022 11:18, Ihor Radchenko wrote:
Max Nikulin writes:
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
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59275
According to the discussion on debbugs, it looks
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> > (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-less
Max Nikulin writes:
> > (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
I submitt
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 we
Max Nikulin writes:
> This one is not consistent with what I see on Linux with glibc.
Yeah, I noticed. :)
> Perhaps you do not have en_US locale generated
>
> locale -a | grep en_US
> en_US.utf8
$ locale -a | grep en_US
en_US.US-ASCII
en_US.UTF-8
en_US
en_US.ISO8859-15
en_US.ISO8859-1
> Sanit
On 09/10/2022 22:38, Rudolf Adamkovič wrote:
For the two examples given by Max on Linux, I get on macOS:
printf 'a\nB\n' | LC_COLLATE=C sort
B
a
This is the expected behavior.
printf 'a\nB\n' | LC_COLLATE=en_US.UTF-8 sort
B
a
This one is not consistent with what I see on Linux with glibc.
Ihor Radchenko writes:
> Rudolf, can you (1) try sort in terminal to confirm that "C" locale
> behaves as expected in MacOS; (2) If sort works fine, you may consider
> reporting Emacs bug.
For the two examples given by Max on Linux, I get on macOS:
printf 'a\nB\n' | LC_COLLATE=C sort
B
a
print
[I am adding Rudolf's email back to CC just in case]
Max Nikulin writes:
>> Should we then modify the test to set locale explicitly?
>
> Rudolf cited the context of this test and "C" locale is explicitly used
> there.
Oops. Missed it. Thanks for the clarification.
>> Note that Rudolf is using
On 08/10/2022 12:25, Ihor Radchenko wrote:
Max Nikulin writes:
When case is not ignored (4th argument is nil) locale-dependent
collation rules are used, so you get the expected result.
$ printf 'a\nB\n' | LC_COLLATE=C sort
B
a
$ printf 'a\nB\n' | LC_COLLATE=en_US.UTF-8 sort
a
B
Should we the
Max Nikulin writes:
> On 07/10/2022 03:15, Rudolf Adamkovič wrote:
>>
>> If I understand, "a" should be less than "B" when under "C" locale when
>> ignoring case (nil) , right? Yet, I get the following:
>>
>> (string-collate-lessp "a" "B" "C" nil) ; => nil
>
> When case is not ignored (4th ar
On 07/10/2022 03:15, Rudolf Adamkovič wrote:
If I understand, "a" should be less than "B" when under "C" locale when
ignoring case (nil) , right? Yet, I get the following:
(string-collate-lessp "a" "B" "C" nil) ; => nil
When case is not ignored (4th argument is nil) locale-dependent
collat
Howdy, howdy!
I see the test failure below on macOS.
Test test-org-table/sort-lines condition:
(ert-test-failed
((should
(equal "| a | x |\n| B | 4 |\n| c | 3 |\n"
(org-test-with-temp-text "| a | x |\n| c | 3 |\n| B | 4 |\n"
... ...)))
:form
(equal "| a
28 matches
Mail list logo