GNU bug report logs - #57079
29.0.50; Performance of seq-uniq is not very good

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefan <at> marxist.se>

Date: Tue, 9 Aug 2022 16:12:02 UTC

Severity: minor

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 57079 <at> debbugs.gnu.org, stefan <at> marxist.se, Juri Linkov <juri <at> linkov.net>
Subject: bug#57079: 29.0.50; Performance of seq-uniq is not very good
Date: Sat, 20 Aug 2022 11:19:24 +0200
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Are we going to merge (or cherry pick) stuff from seq.el to cl-lib?
> Probably not, so let's disregard the idea that cl-lib will ever be a
> complete replacement for seq.el stuff.

Why probably not?  We used to limit ourselves to what was in Common Lisp
when the library was called cl.el, but now that it's cl-lib.el, we've
opened up the possibility of adding whatever we think is useful in
Emacs.

> If you can't: seq.el has lots of overlaps with other parts of Emacs.
> What is so special about CL that an overlap is not acceptable?  Or what
> is special about this task that it is not possible to handle it in
> several places?

I'm just explaining why the design of seq.el is the way that it is: It's
the way it is because the person who wrote it wanted a sequence library
with a simple, extremely regular interface.





This bug report was last modified 3 years and 2 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.