bug#41706: 26.1; sort-subr predicate cannot be set successfully

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: post+ebugs@guelker.eu,  41706@debbugs.gnu.org
> Date: Thu, 11 Jun 2020 15:59:39 +0200
> 
> Eli Zaretskii <eliz@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.

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.