[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CL package serious deficiencies

From: Drew Adams
Subject: RE: CL package serious deficiencies
Date: Wed, 8 Feb 2012 06:26:10 -0800

> We already have at least the following Org-specific re-writes
> of existing cl-functions, and we frequently have
> to cull other cl functions from the code base.
> org-count
> org-find-if
> org-reduce
> org-remove-if
> org-remove-if-not

Likewise, for my code (e.g. Icicles, Bookmark+) - same usual suspects: simple
sequence functions.  Not a biggee, but a clear hint, no?

> M-x apropos "remove-if" yields the following 9 functions all of
> which are currently distributed as part of Emacs. 
> ert--remove-if-not
> gnus-remove-if
> gnus-remove-if-not
> org-remove-if
> org-remove-if-not
> recentf-remove-if-non-kept
> remove-if
> remove-if-not
> widget-remove-if

This is precisely what I meant by:

>> 5. IMO it makes sense to proceed gradually, and to start by
>>    including more of the simpler things that do work well,
>>    even if in a limited way, into regular Emacs Lisp.

Such sequence functions (or similar) are one obvious place to start, IMHO.  And
preferably _with_ support for at least some keyword arguments (or else
equivalent, non-keyword args) - in particular, :test and :key.

But hey, we still do not have a fast version of `remove-duplicates' -

And that's perhaps an example of one of the problems with cl.el: the cl.el
version of `remove-duplicates' is actually much _slower_ than the typical naive
Lisp definition.


>> 6. We've been through this (#5) before.  Candidate functions
>>    have been nominated and discussed.  Some people have longer
>>    wishlists of functions than others.  But little to nothing
>>    comes of it.  Dommage, IMO.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]