From: Michael Heerdegen <michael_heerdegen@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 41706@debbugs.gnu.org, post+ebugs@guelker.eu
Subject: bug#41706: 26.1; sort-subr predicate cannot be set successfully
Date: Thu, 11 Jun 2020 15:59:39 +0200 [thread overview]
Message-ID: <87pna5put0.fsf@web.de> (raw)
In-Reply-To: <838sgt67rk.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 11 Jun 2020 16:39:59 +0300")
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.
next prev parent reply other threads:[~2020-06-11 13:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 11:09 bug#41706: 26.1; sort-subr predicate cannot be set successfully Marvin Gülker
2020-06-04 12:11 ` Michael Heerdegen
2020-06-04 19:05 ` Marvin Gülker
2020-06-05 8:32 ` Eli Zaretskii
2020-06-05 9:43 ` Michael Heerdegen
2020-06-05 11:43 ` Eli Zaretskii
2020-06-10 18:59 ` Michael Heerdegen
2020-06-10 19:08 ` Eli Zaretskii
2020-06-11 12:55 ` Michael Heerdegen
2020-06-11 13:39 ` Eli Zaretskii
2020-06-11 13:59 ` Michael Heerdegen [this message]
2020-06-11 16:36 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pna5put0.fsf@web.de \
--to=michael_heerdegen@web.de \
--cc=41706@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=post+ebugs@guelker.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.