[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69709: `sort` interface improvement and universal ordering predicate
From: |
Mattias Engdegård |
Subject: |
bug#69709: `sort` interface improvement and universal ordering predicate |
Date: |
Fri, 29 Mar 2024 16:02:01 +0100 |
29 mars 2024 kl. 13.06 skrev Eli Zaretskii <eliz@gnu.org>:
> . The description of value< says "lexicographic order" about some
> types, but I think that is not clear enough, and we should tell
> explicitly how the comparison works in those cases.
That's a good point. Since it is standard terminology I will explain it in the
manual but leave the doc string as it is -- this is our usual practice, right?
> . AFAICT, no ordering is defined for overlays, and I wonder why. I
> think this could be very useful; we certainly sort overlays in C in
> several places.
Yes, the plan was to add ordering for more types as we figure out which ones
are missing. Basically, if a type has a useful ordering that is well-defined,
we should probably add it.
That's one reason why I didn't include overlays from the beginning: I couldn't
easily find one obvious ordering that would make intuitive sense, and I'd
rather leave them unordered than define something useless. Code that sorts
overlays uses a variety of criteria: priority, starting position,
application-specific properties, and so on.
> . Various fine details about value< are never mentioned: the fact
> that there's a limit to recursion, the special treatment of nil in
> some cases, etc. I think we should document them, at least in the
> doc string if not in the manual as well.
Right -- the depth limit is very much like that of `equal` which is documented
in the manual but not the doc string; I'll probably do the same for `value<`.
`nil` deserves a note about its dual nature (symbol and list) as well.
Thank you for the markup fixes, by the way. One question:
> -@table @asis
> +@table @code
I used @asis because that is what the entries for some other functions using
key-value arguments used, like `make-process`. Clearly the keyword should be
marked up as @code, but should it encompass the @var{argument} part as well? Or
should we use @asis and then explicit @code in each @item?
- bug#69709: `sort` interface improvement and universal ordering predicate, (continued)
- bug#69709: `sort` interface improvement and universal ordering predicate, Mattias Engdegård, 2024/03/23
- bug#69709: `sort` interface improvement and universal ordering predicate, Dmitry Gutov, 2024/03/23
- bug#69709: `sort` interface improvement and universal ordering predicate, Stefan Monnier, 2024/03/23
- bug#69709: `sort` interface improvement and universal ordering predicate, Dmitry Gutov, 2024/03/23
- bug#69709: `sort` interface improvement and universal ordering predicate, Stefan Monnier, 2024/03/23
- bug#69709: `sort` interface improvement and universal ordering predicate, Mattias Engdegård, 2024/03/25
- bug#69709: `sort` interface improvement and universal ordering predicate, Mattias Engdegård, 2024/03/29
- bug#69709: `sort` interface improvement and universal ordering predicate, Daniel Mendler, 2024/03/29
- bug#69709: `sort` interface improvement and universal ordering predicate, Mattias Engdegård, 2024/03/29
- bug#69709: `sort` interface improvement and universal ordering predicate, Eli Zaretskii, 2024/03/29
- bug#69709: `sort` interface improvement and universal ordering predicate,
Mattias Engdegård <=
- bug#69709: `sort` interface improvement and universal ordering predicate, Eli Zaretskii, 2024/03/29
- bug#69709: `sort` interface improvement and universal ordering predicate, Mattias Engdegård, 2024/03/29
- bug#69709: `sort` interface improvement and universal ordering predicate, Eli Zaretskii, 2024/03/29
bug#69709: `sort` interface improvement and universal ordering predicate, Dmitry Gutov, 2024/03/10
bug#69709: `sort` interface improvement and universal ordering predicate, Gerd Möllmann, 2024/03/11