[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41706: 26.1; sort-subr predicate cannot be set successfully
From: |
Michael Heerdegen |
Subject: |
bug#41706: 26.1; sort-subr predicate cannot be set successfully |
Date: |
Thu, 11 Jun 2020 15:59:39 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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.
> > 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.
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Marvin Gülker, 2020/06/04
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Michael Heerdegen, 2020/06/04
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Marvin Gülker, 2020/06/04
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Eli Zaretskii, 2020/06/05
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Michael Heerdegen, 2020/06/05
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Eli Zaretskii, 2020/06/05
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Michael Heerdegen, 2020/06/10
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Eli Zaretskii, 2020/06/10
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Michael Heerdegen, 2020/06/11
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Eli Zaretskii, 2020/06/11
- bug#41706: 26.1; sort-subr predicate cannot be set successfully,
Michael Heerdegen <=
- bug#41706: 26.1; sort-subr predicate cannot be set successfully, Eli Zaretskii, 2020/06/11