[Top][All Lists]

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

RE: sea-level rise of byte-compilation warnings [was: Fixing...byte-com

From: Drew Adams
Subject: RE: sea-level rise of byte-compilation warnings [was: Fixing...byte-compilation warnings...]
Date: Mon, 16 Nov 2015 15:52:17 -0800 (PST)

> In my experience, 90% of the superfluous warnings are silenced by a
> `defvar' or a `declare-function'. Finally, with-no-warnings should cover
> the last 10. If this isn't well documented it really should be.

Those are not supported in all Emacs versions.  That is the reason
I don't use them in some libraries.

> > The degree of warning is now overkill in many contexts
> > (even for novices, it could be argued).
> I don't usually feel overwhelmed by the warnings. Most of my elisp files
> have 0 to 3 of these warning-suppressing forms. Only the really large
> projects with 10+ files end up having a lot.

Different users will get different floods of warnings.  The older
the Emacs versions your libraries support, the deeper the flood,
other things being equal.

The warnings don't really bother me.  What bothers me somewhat
are the fact that they bother users of my libraries.  I need to
let them know that there is no problem.

> I'm curious what are your contexts. I guess you're supporting Emacs
> versions < 24.1?

I am, for many of my libraries, but not for all.  If a new library
makes use of constructs from Emacs N then I generally support only
N and greater.

> > What is needed is to:
> >
> > * be able to notice the important ones, while also
> >   showing ones that are less important
> Different warning levels might be nice, but (looking at
> `byte-compile-warnings') the only warnings that don't immediately mean
> “this code might break” are the `cl-functions', `obsolete', and
> `mapcar'. So I don't know how much it would help your warning flood.

`obsolete' certainly does.  I continue to (and will continue to) use
"obsolete" constructs.

But the topic is not about me or my use.  It's a general topic.

> > * be able to have the code itself easily (and
> >   conditionally) inhibit them - as a whole or by type
> Like I said, with-no-warnings inhibits them locally, but I perfectly
> agree there should be a way to suppress warnings on a file-local (and
> maybe dir-local) basis.

(FWIW, `with-no-warnings' is not available in Emacs 20.
Lots of my code works also in Emacs 20, intentionally.)

> > FWIW, my crystal ball whispers that just analyzing
> > the code for sexps that are protected by `fboundp'
> > might go a long way toward eliminating many spurious
> > warnings.
> My psychic senses agree.

reply via email to

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