From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41706: 26.1; sort-subr predicate cannot be set successfully Date: Thu, 11 Jun 2020 19:36:09 +0300 Message-ID: <834krh5zly.fsf@gnu.org> References: <20200604110922.GA9116@atlantis> <87pnafxc7e.fsf@web.de> <20200604190526.GA14104@atlantis> <83d06dc3po.fsf@gnu.org> <87h7vpg85k.fsf@web.de> <83a71hbuvo.fsf@gnu.org> <874kriiw6l.fsf@web.de> <83k10e68nu.fsf@gnu.org> <87tuzhpxsd.fsf@web.de> <838sgt67rk.fsf@gnu.org> <87pna5put0.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="70035"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41706@debbugs.gnu.org, post+ebugs@guelker.eu To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 11 18:43:37 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jjQIj-000I7F-Cj for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Jun 2020 18:43:37 +0200 Original-Received: from localhost ([::1]:49446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjQIi-0007oL-Ee for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Jun 2020 12:43:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jjQCM-0000dv-K5 for bug-gnu-emacs@gnu.org; Thu, 11 Jun 2020 12:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54592) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jjQCM-0001DO-7y for bug-gnu-emacs@gnu.org; Thu, 11 Jun 2020 12:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jjQCL-0001Na-Ve for bug-gnu-emacs@gnu.org; Thu, 11 Jun 2020 12:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jun 2020 16:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41706 X-GNU-PR-Package: emacs Original-Received: via spool by 41706-submit@debbugs.gnu.org id=B41706.15918933925240 (code B ref 41706); Thu, 11 Jun 2020 16:37:01 +0000 Original-Received: (at 41706) by debbugs.gnu.org; 11 Jun 2020 16:36:32 +0000 Original-Received: from localhost ([127.0.0.1]:37895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjQBs-0001MR-2z for submit@debbugs.gnu.org; Thu, 11 Jun 2020 12:36:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:32944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjQBp-0001MC-St for 41706@debbugs.gnu.org; Thu, 11 Jun 2020 12:36:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37447) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjQBj-00015F-Pv; Thu, 11 Jun 2020 12:36:23 -0400 Original-Received: from [176.228.60.248] (port=3264 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jjQBj-0002o9-88; Thu, 11 Jun 2020 12:36:23 -0400 In-Reply-To: <87pna5put0.fsf@web.de> (message from Michael Heerdegen on Thu, 11 Jun 2020 15:59:39 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181862 Archived-At: > From: Michael Heerdegen > Cc: post+ebugs@guelker.eu, 41706@debbugs.gnu.org > Date: Thu, 11 Jun 2020 15:59:39 +0200 > > Eli Zaretskii writes: > > > > +second key. The key values PREDICATE is called with are the > > > +either the return values of STARTKEYFUN when that function is > > > +specified and returns a non-nil value. > > > > The last sentence is incomplete and/or needs some fixing, AFAICT. > > If you mean something else than in you subsequent comment, please > elaborate. I meant that a sentence which says "either ..." is expected to say "or ..." at some later point, and also that "are the either the return values" doesn't sound correct English to me. > > > In any other case the keys > > > +are cons cells of the form (BEG . END), where BEG is the value of > > > +point after calling STARTKEYFUN when given, else after calling > > > +ENDRECFUN, and END is the value of point after calling ENDKEYFUN when > > > +given, and after calling ENDRECFUN else. > > > > This seems to contradict the following part, which seems to say that > > the key arguments are not always cons cells: > > > > > +If PREDICATE is nil, comparison is done with `<' if > > > the keys are numbers, with `compare-buffer-substrings' if the > > > keys are cons cells (the car and cdr of each cons cell are taken > > > as start and end positions), and with `string<' otherwise." > > > > Am I missing something? > > Not really. AFAIU the only case where this applies is when STARTKEYFUN > is specified and returns values of this type - else `sort-build-lists' > always generates conses. I think this should be stated in the doc string, not implied. > > > What I also would like to add to the docstring of this function, and of > > > that of `sort', is that the PREDICATE must be transitive and > > > antisymmetric - mentioning only in the manual is not enough IMHO. > > > > Fine with me, provided that you explain what those two attributes > > mean. > > Is it enough to relegate to the manual? Not IMO. > > The main problem with collation is that it's locale-specific, and > > different C libraries implement collation for the same locale in > > slightly different ways. The result is that the sorted text may not > > be the same even if you do that on two systems in the same locale. > > How would you suggest to solve this issue? > > I have no clue. Is this a general requirement? It doesn't have to be a requirement, but if it isn't, then what is the utility of an API that yields different results in different environments? What is/are the use case(s) you have in mind? > For `sort-subr' I think > the requirement is not so much absolute reproducibility (sorry if that > word doesn't exist) but that it is able to sort lexicographically in a > reasonably sensible way. My point is that lexicographical sorting is locale dependent, and some people might be surprised by seeing a sort after A, but before B. However, if this is clearly documented, I guess it's up to the Lisp programs that call such an API to deal with the consequences. Bonus points for allowing the caller to specify the locale, like string-collate-lessp does.