Re: cc-vars.el

[Martin Stjernholm <mast@lysator.liu.se>]

Dave Love <d.love@dl.ac.uk> wrote:

> /.../ There are typically still some compilation warnings if you do
> portability stuff cleanly, but they're not usually excessive.

I consider anything more than two warnings all-in-all to be too
excessive. After that it's too easy to get accustomed to them and stop
looking carefully enough.

> 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.

True, but it's more valid within different versions of the same
branch, e.g. between Emacs 20 and 21, and even more so between minor
versions. I had at one point a simple macro system that tested all
this at compile time and made completely tailored byte code, and I got
a complaint from a user then. I don't remember between what exact
versions he tried to port it, but a single complaint isn't much of
test data anyway. From it I can only draw the conclusion that the
problem exists, not at all how big or small it is.

The only way to avoid compiler warnings cleanly (in some sense) is to
do the tests with macros at compile time, but that is apparently not a
good solution. Thus, the only resort is to make these kludgy symbol
and variable bindings.

> /.../ Changes to the compiler would help, e.g. to avoid warnings
> from
> 
>  (unless (fboundp 'fred)
>    (define fred ...))

It's possible to do something like this without any compiler warnings
at all; that's essentially what cc-bytecomp-defun does (and now it
hopefully does it correctly too). The problem is not there but rather
that it's necessary to actually bind the symbols to get rid of the
warnings since there is no other way to hook into the compiler to
control them.

> 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.

Don't you rather mean code like this?

    (if (fboundp 'fred)
        (fred ...))

It'd be cool if the compiler did enough flow analysis to cope with
that, but it might be hard to get it to work well, and if it doesn't
work well then I'd prefer to have the possibility to control the
warnings explicitly with some pragma-like system.

It's really the lack of such a system in the byte compiler that is the
problem here.

An interesting angle is if something like the following can be used
(although I'd consider this too a workaround rather than a solution):

    (if (boundp 'fido)
        (symbol-value 'fido))
    (if (fboundp 'fred)
        (funcall 'fred ...))

Someone with insight in the inner workings of the compiler can perhaps
advice on how effectively it manages to optimize such things.

> 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.

That is a valid point to some extent, but it's a choice I prefer to
make myself when it comes to my own "upstream" development CC Mode. I
approach it this way: If there's some _specific_ feature in newer
emacsen that would give a real benefit, and if I think it's too hard
to implement compatibility kludges for it, then and only then do I
scrap compatibility. (Thus I don't consider an argument that a kludge
just looks big and ugly as a valid reason for dropping it.)

Anyway, this is besides the point regarding cc-bytecomp, since that
one is necessary to keep it working and compiling without warnings on
both Emacs and XEmacs. It's actually the support for both flavors that
is responsible for approximately 90% of all the time I spend on
compatibility kludges. It also means I can't use a new feature until
it's so old that it exist in the other flavor, in at least an
approximately similar form. (Such a feature is the syntax-table text
property, which I intend to make greater use of and which will be the
specific reason that CC Mode soon will ditch support for Emacs 19 and
XEmacs 19 and 20.)

As for the distribution in Emacs I don't really have any objections if
someone decides to rip out all the compatibility code, except for one
thing: The ripping-out itself is a possible source of errors, and I
wouldn't like to have to spend time on hunting down bugs due to that
which gets reported to me.