[Top][All Lists]

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

Re: cc-vars.el

From: Dave Love
Subject: Re: cc-vars.el
Date: 18 Nov 2002 19:51:54 +0000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Kenichi Handa <address@hidden> writes:

> But, Richard is against cc-bytecomp-defun.  He wrote:
> Richard Stallman <address@hidden> writes:
> >     + 2002-11-14  Kenichi Handa  <address@hidden>
> >     + 
> >     +       * progmodes/cc-vars.el: Don't cc-bytecomp-defun char-table-p.
> >     + 
> > I think that is the right fix--this cc-bytecomp-defun is a bad kludge.
> > I am thinking that maybe we should get rid of it because it is so
> > risky.
> > I had undone Dave's change in set-buffer-file-coding-system to fix this,
> > but I restored that change today after concluding that cc-bytecomp-defun
> > is the real culprit.
> Martin, could you discuss this issue with Richard from now
> on.  I don't have any strong opinion on this issue.

I still don't understand how what I did affected this, but then I
didn't try to use cc-mode in the bootstrapped result.  However, I
strongly agree with rms.  I didn't realize cc-mode was doing that, but
I'm sure it shouldn't.

I've previously fixed Gnus and W3 to avoid special compilation
mechanisms like that.  Apart from being probably unsuitable for
installing in Emacs, they actually hid bugs.  There are typically
still some compilation warnings if you do portability stuff cleanly,
but they're not usually excessive.  Changes to the compiler would
help, e.g. to avoid warnings from

 (unless (fboundp 'fred)
   (define fred ...))

A change for that I once suggested greatly reduced the noise and I
don't think it's a big issue to re-write a few things to forms such a
compiler check would be documented to recognize.

I see a comment in cc-bytecomp implying that compilation is supposed
to produce byte code that's portable between Emacs and XEmacs, but
that's a lost cause.  They are (now) basically incompatible,
e.g. XEmacs byte code can crash Emacs if you force it to be loaded.
This means that the compiler can reasonably eliminate code conditional
on `(featurep 'xemacs)', for instance, reducing spurious warnings
again and perhaps improving efficiency in a few cases.

I also think it's unwise to try to support ancient versions of
(X)Emacs.  That just makes life difficult and takes resources that
could be put into improvements for current versions, especially taking
advantage of new features.

Sorry if that sounds like just a gripe, but it's from a fair amount of
experience. :-/

reply via email to

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