GNU bug report logs - #41706
26.1; sort-subr predicate cannot be set successfully

Previous Next

Full log

Message #35 received at 41706 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41706 <at> debbugs.gnu.org, post+ebugs <at> guelker.eu
Subject: Re: bug#41706: 26.1; sort-subr predicate cannot be set successfully
Date: Thu, 11 Jun 2020 15:59:39 +0200

Eli Zaretskii <eliz <at> gnu.org> 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.

> >                                         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.  The different defaults of PREDICATE depending
on some types of STARTKEYFUN seem to be predefined just for convenience.

> > 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?

> 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?  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.

Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.