emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: test-org-table/sort-lines: Failing test on macOS
Date: Wed, 23 Nov 2022 22:27:35 +0700	[thread overview]
Message-ID: <tlle59$pl3$1@ciao.gmane.io> (raw)
In-Reply-To: <87k03mhs8b.fsf@localhost>

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 presented to humans.

(setq lst '("semana" "señor" "sepia"))
(sort lst #'string-lessp) ;         => ("semana" "sepia" "señor")
(sort lst #'string-collate-lessp) ; => ("semana" "señor" "sepia")

> Eli even argued that `string-collate-lessp' is strictly worse compared
> to more predictable approach. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59275#40

In this particular case Eli may assume that e.g. list is a elisp 
structure, not a kind of text formatting. In general, I am quite 
pessimistic concerning quality of locales support in Emacs while Eli may 
have rather different point of view.

> Do you remember any cases when users actually demanded locale-specific
> sorting?

I think, users too often face poor locale support in various 
applications, so they are not surprised when see incorrect results. In 
some sense such results are consistent (erroneous in the same way).

Formatting of numbers in Emacs is the extreme case of consistency. For 
the sake of reliably reading/writing of numbers from/to files or network 
it is impossible to present a number accordingly to the current locale. 
An exception is en_US that has some dedicated code in calc.

I believe, it is silly to adhere to a common denominator and to not use 
`string-collate-lessp' just because it is unavailable in some environments.

> 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 environments (OSes) are not 
equal and quality of locale support varies. Emacs heavily depends on 
libc in this area.

>> However I am afraid of compatibility shims after
>>
>> d3a9c424b 2022-08-16 17:15:27 +0800 Ihor Radchenko: org-encode-time:
>> Refactor into top-level `defmacro'
> 
> What do you refer to?

Implementation must be chosen at compile (or load) time. Due to some 
issues with native compiling it does not work. For string comparison 
runtime performance penalty may be higher than for timestamp processing.

> The question is what can be done and, more importantly, how much effort
> will it take to implement and maintain an alternative.

Effort is significant however e.g. browsers have their own 
implementation of Unicode-related stuff. There is ICU library, but Eli 
is against it because Emacs already has partial implementation of 
Unicode and it would mean duplication of character database.




  reply	other threads:[~2022-11-23 15:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 20:15 test-org-table/sort-lines: Failing test on macOS Rudolf Adamkovič
2022-10-07 12:04 ` Max Nikulin
2022-10-08  5:25   ` Ihor Radchenko
2022-10-08 14:27     ` Max Nikulin
2022-10-09  3:59       ` Ihor Radchenko
2022-10-09 15:38         ` Rudolf Adamkovič
2022-10-09 16:53           ` Max Nikulin
2022-10-10 22:25             ` Rudolf Adamkovič
2022-10-12 16:09               ` Max Nikulin
2022-11-15  4:10                 ` Ihor Radchenko
2022-11-20  4:18                   ` Ihor Radchenko
2022-11-20  8:00                     ` Max Nikulin
2022-11-21  3:15                       ` Ihor Radchenko
2022-11-21 16:48                         ` Max Nikulin
2022-11-22  1:14                           ` Ihor Radchenko
2022-11-22 16:01                             ` Max Nikulin
2022-11-23 10:37                               ` Ihor Radchenko
2022-11-23 15:27                                 ` Max Nikulin [this message]
2022-11-23 17:01                                   ` Max Nikulin
2022-11-26  2:05                                   ` Ihor Radchenko
2022-11-29 16:40                                     ` Max Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='tlle59$pl3$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).