[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we just start dumping cl-lib?
From: |
Mark Oteiza |
Subject: |
Re: Should we just start dumping cl-lib? |
Date: |
Fri, 2 Oct 2015 10:14:52 -0400 |
User-agent: |
Mutt/1.5.24+19 (9de2f1c6da87) (2015-08-30) |
On 02/10/15 at 04:45pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <address@hidden>
> > Date: Fri, 02 Oct 2015 07:46:46 -0400
> >
> > I'd be happy to have more useful functions in "core". (Can we have
> > `filter` yet?)
>
> Please always accompany such suggestions with rationale. Adding to
> the core just because "why not?" is IMO not a good methodology. Some
> people still care about the memory footprint of programs, so we don't
> want to bloat that unless there are good reasons. Such reasons can
> only be discussed on a case by case basis.
Understood, thanks.
Regarding the breakage with winner.el, I don't understand why under some
circumstances nothing seems to break if cl- functions are used at
runtime in things with only `(eval-when-compile (require 'cl-lib))`. For
instance, git-grepping for 'cl-remove-if' I see package.el and
checkdoc.el don't require cl-lib at runtime.
Re: Should we just start dumping cl-lib?, Mark Oteiza, 2015/10/08
Re: Should we just start dumping cl-lib?, John Wiegley, 2015/10/08
Re: Should we just start dumping cl-lib?, Daniel Colascione, 2015/10/08
Re: Should we just start dumping cl-lib?, Eli Zaretskii, 2015/10/08
Re: Should we just start dumping cl-lib?, Daniel Colascione, 2015/10/08
Re: Should we just start dumping cl-lib?, Eli Zaretskii, 2015/10/08