Re: Should we just start dumping cl-lib?

[Artur Malabarba]

I agree. seq-filter is fine and seq.el is bundled with Emacs, so it should be enough. There's also an equivalent in cl under a different name.

We have enough unprefixed symbols already, let's not start adding more unless they are very basic things like `def` macros or flow control macros.

On 2 Oct 2015 2:37 pm, "Tassilo Horn" <address@hidden> wrote:
>
> Mark Oteiza <address@hidden> writes:
>
> >> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when
> >> winner was enabled without cl-lib being loaded. Nobody seems to have
> >> noticed until now, which suggests that either almost nobody uses
> >> winner, or almost everybody has cl-lib loaded anyway. Maybe it's time
> >> to just dump cl-lib with Emacs.
> >
> > Bug#21549
> >
> > I'd be happy to have more useful functions in "core". (Can we have
> > `filter` yet?)
>
> There are `seq-filter', `seq-remove', `seq-map', `seq-mapcat',
> `seq-reduce', etc. in the new seq.el, and a nice API for associative
> structures in map.el which are in "core" although not dumped just like
> cl-lib.
>
> Many seq.el functions have cl-lib counterparts which do pretty much the
> same.  So the decision if cl-lib should be dumped is also a strategic
> decision.  Do we want to advocate seq.el or cl-lib?  (Well, right now
> seq.el depends on cl-lib so we couldn't dump seq.el without cl-lib but
> anyway...)
>
> Bye,
> Tassilo
>