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 16:39:59 +0300 Message-ID: <838sgt67rk.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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="34418"; 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 15:42:20 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 1jjNTI-0008s8-J0 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Jun 2020 15:42:20 +0200 Original-Received: from localhost ([::1]:34452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjNTH-0007fT-Ew for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Jun 2020 09:42:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jjNS3-0005b3-0V for bug-gnu-emacs@gnu.org; Thu, 11 Jun 2020 09:41:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53049) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jjNS2-00065N-Jm for bug-gnu-emacs@gnu.org; Thu, 11 Jun 2020 09:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jjNS2-0002JW-Hi for bug-gnu-emacs@gnu.org; Thu, 11 Jun 2020 09:41:02 -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 13:41:02 +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.15918828298828 (code B ref 41706); Thu, 11 Jun 2020 13:41:02 +0000 Original-Received: (at 41706) by debbugs.gnu.org; 11 Jun 2020 13:40:29 +0000 Original-Received: from localhost ([127.0.0.1]:36362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjNRU-0002IK-Nt for submit@debbugs.gnu.org; Thu, 11 Jun 2020 09:40:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjNRS-0002I3-Kq for 41706@debbugs.gnu.org; Thu, 11 Jun 2020 09:40:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33886) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjNRM-0005sI-Ai; Thu, 11 Jun 2020 09:40:20 -0400 Original-Received: from [176.228.60.248] (port=4398 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jjNRK-0004Uy-Dy; Thu, 11 Jun 2020 09:40:19 -0400 In-Reply-To: <87tuzhpxsd.fsf@web.de> (message from Michael Heerdegen on Thu, 11 Jun 2020 14:55:14 +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:181852 Archived-At: > From: Michael Heerdegen > Cc: post+ebugs@guelker.eu, 41706@debbugs.gnu.org > Date: Thu, 11 Jun 2020 14:55:14 +0200 > > > . the cons cell case hints on a possible return value of STARTKEYFUN, > > AFAIU, but the text doesn't say so > > . the case of STARTKEYFUN being nil is another use case for what > > PREDICATE must cope with, and the text should say so > > . the text about ENDKEYFUN should also be augmented, IMO > > . the description of PREDICATE should reference this text in some > > useful way > > I must admit I found the doc sufficient for all of these. Actually, > reading the implementation might be simpler than describing it: It is? if so, that's a clear sign that the description "needs work", IME. > --- a/lisp/sort.el > +++ b/lisp/sort.el > @@ -80,7 +80,15 @@ sort-subr > PREDICATE, if non-nil, is the predicate function for comparing > keys; it is called with two arguments, the keys to compare, and > should return non-nil if the first key should sort before the > -second key. If PREDICATE is nil, comparison is done with `<' if > +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. > 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? > 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. > > > BTW, what about the suggestion to support collation order out of the > > > box? > > > > What collation would you like to support, and in what form? > > I don't know much about this stuff. The canonical way from my ignorant > point of view would be that `compare-buffer-substrings' would not only > respect `case-fold-search' but also some other variable which would tell > how the behavior should be w.r.t. collation. 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?