Re: master 4b79c80c999 1/2: New function 'sort-on'

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> This function can only sort lists, so at least from that aspect its
> place is not in seq.el.  In addition, I see no reason to have it
> preloaded.
>
> I've put it in sort.el because the function 'sort' is there.

Both places make no sense to me.  sort.el doesn't define `sort' - it's
completely and only about sorting _text_ entities.  Reverse lines or
columns etc.  The new function doesn't fit there.  Maybe subr.el or
subr-x.el?

Here are two more typos, @Eli please review and install if you agree.  I
guess there could be more, I only have had a quick look at the text:

>From cd94b493a50d98623c5d354ca9dac854bfc6cf6a Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Fri, 2 Feb 2024 16:23:23 +0100
Subject: [PATCH] Fix more typos in 'sort-on' change

---
 doc/lispref/sequences.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi
index 896dac35c8e..28b9591a148 100644
--- a/doc/lispref/sequences.texi
+++ b/doc/lispref/sequences.texi
@@ -462,8 +462,8 @@ Sequence Functions
 This function implements what is known as
 @dfn{decorate-sort-undecorate} paradigm, of the Schwartzian transform.
 It basically trades CPU for memory, creating a temporary list with the
-computed sport keys, then mapping @code{car} over the result of
-sorting that temporary list.  Unlike with @code{sort}, the return list
+computed sort keys, then mapping @code{car} over the result of
+sorting that temporary list.  Unlike with @code{sort}, the returned list
 is a copy; the original list is left intact.
 @end defun
 
-- 
2.39.2


Thx,

Michael.