bug#59275: Unexpected return value of `string-collate-lessp' on Mac

[Eli Zaretskii <eliz@gnu.org>]

> From: Maxim Nikulin <m.a.nikulin@gmail.com>
> Date: Sun, 27 Nov 2022 21:00:50 +0700
> Cc: 59275@debbugs.gnu.org
> 
> Concerning Org, my point is that caseless sorting should be uniform. 

You need to work hard to get that.  Just using 'downcase' is not enough, and
neither is using 'string-collate-equalp'.

> >> https://nullprogram.com/blog/2014/06/13/ that mentioned something
> >> similar about caveats with composition.
> > 
> > I don't see there anything about sorting or collation.  What did I miss?
> 
> Does not composed/decomposed representation affect comparison result?

They are different texts, so yes, they do, and they should.
If you want to treat such strings as equivalent, you need to work even
harder, since Emacs currently doesn't have enough infrastructure to do it
right in all cases.

> 
> Emacs-devel thread mentioned earlier in this bug contains a link 
> describing enough issues with string comparison:
> 
> https://stackoverflow.com/questions/319426/how-do-i-do-a-case-insensitive-string-comparison

This is about Python, no?

> From my point of view e.g. case transformation rule for Turkish I is a
> minor issue

Why, Org doesn't want to support Turkish users?

> My argument against `downcase' in `string-collate-lessp' is that it may 
> add noticeable performance penalty.

I'd worry about correctness before performance.

> Interestingly `compare-strings' uses upcase conversion when the 
> IGNORE-CASE argument is true. I believed that some implementations 
> (unrelated to Emacs) may have problems with e.g. ß and considered 
> downcase as a safer option.

Case conversions always have problems.