[Top][All Lists]

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

Re: cc-vars.el

From: Stefan Monnier
Subject: Re: cc-vars.el
Date: Wed, 20 Nov 2002 10:01:19 -0500

> > But I also completely agree that we should try to make sure that pragmas
> > as needed as rarely as possible, so I wholeheartedly support Dave's
> > suggestion which will at least reduce the amount of useless warnings.
> One of the problems I've seen is with code which is conditioned to
> differentiate between either gnu emacs and xemacs, or between different
> os-types.

This is irrelevant: Dave's patch doesn't impact those cases at all.

> In the first case, many packages seem to have their own "xyz-xemacs-p"
> function or variable, and the bytecompiler will surely have a hard time
> determining whether a piece of code isn't used at all on this platform.

And it shouldn't: the code should simply be fixed.  In 90% of the
time an fboundp check would be better (and Dave's patch would then have
a chance of understanding what's going on).

> A new built-in variable `emacs-type' (value = 'gnu-emacs or e.g. 'xemacs)
> would fix this problem; for portability, packages may add the following
> snippet to support older versions of gnu and xemacs:

We don't want to encourage people to use brain dead tests like those.
There's already (featurep 'xemacs) for such things.
Maybe we should add to byte-opt.el the following snippet:

   (put 'featurep 'byte-optimizer 'byte-optimize-featurep)
   (defun byte-optimize-featurep (form)
     (if (equal '(featurep 'xemacs) form) nil form))

since Emacs-21's byte-code won't work on XEmacs anyway, there's no
point keeping XEmacs code around.  It makes the code shorter and
gets rid of a few warnings.


reply via email to

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