emacs-devel
[Top][All Lists]
Advanced

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

Re: CL package serious deficiencies


From: Alan Mackenzie
Subject: Re: CL package serious deficiencies
Date: Tue, 7 Feb 2012 22:16:53 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi, Daniel.

On Tue, Feb 07, 2012 at 01:34:06PM -0800, Daniel Colascione wrote:
> On 2/7/12 1:23 PM, Nix wrote:
> > (FWIW, the *last* time I asked about this, many years ago, I was told
> > that runtime use of cl was out of the question because it used too much
> > memory. I presume that this argument is obsolete :) )

> I've long been an advocate of dumping cl with Emacs; XEmacs does so
> without problems.

The CC Mode test suite (in particular, 000tests.el, available from the CC
Mode site at SourceForge), uses cl at run time.  It's been getting wierd
"can't happen" errors for years:  some error starts appearing,
repeatedly, then after some unrelated change in CC Mode, stops appearing.
Then another wierd error starts happening, then stops.  This has been
going on for years.  The current error, which has been happening for ~6
months, is:

    Testing awk-face-1.awk (fonts)  Buffer is read-only: #<buffer *cc-test*>

.  This doesn't happen with XEmacs (though other errors do).

I believe that the cl files are somehow responsible; Barry Warsaw (who
originally wrote 000tests.el) was and is a competent hacker.

> CLisms simply result in cleaner, smaller code than one can write using
> nothing but elisp primitives.

> The latest objection is that dumping CL would Emacs would increase the
> size of the printed and bound Emacs Lisp Reference Manual from the
> FSF. I find this objection unconvincing because it applies to _any_ new
> feature, and I don't think we're against adding new features to Emacs.

I'd recommend not changing the policy on CL until it acquires a rigorous
test suite.  I don't really trust it beyond use at byte-compile time.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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