RE: CL package serious deficiencies

[Drew Adams]

> 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' -
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10386#11,
http://article.gmane.org/gmane.emacs.devel/139546/match=remove+dups.

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.

Unfortunately:

>> 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.