all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>, help-gnu-emacs@gnu.org
Subject: worrying about byte-compiler warnings  [was: Flycheck reports are never satisfying!?]
Date: Thu, 28 Aug 2014 08:51:05 -0700 (PDT)	[thread overview]
Message-ID: <8aabfda9-fe74-43ee-92c6-51bf44ffb034@default> (raw)
In-Reply-To: <jwvk35s7kp3.fsf-monnier+gmane.emacs.help@gnu.org>

>> In such cases, the packages (which use "externals") will output as
>> many warnings as well, for references to "undefined variables"?
>
> If you take a 20 year old package that hasn't been updated, then the
> byte-compiler will usually emit many such warnings, yes.

Though it does not make the claim that the presence of many warnings
indicates that a package is out of date, someone might well misread
that statement and be misled by it.

So let me be clear: Byte-compiler warnings are not necessarily a sign
that a package has not been updated or it has a coding problem.

A package that works with multiple Emacs versions will often lead to
byte-compiler warnings, possibly many of them, that do not represent
real problems.

And if the oldest Emacs version supported by a package does not support
things like `declare-function' then there can be even more warnings,
due to function arity changes over time (function-not-known-to-be-defined
warnings).

In general, my advice to package users would be to not worry about
byte-compiler warnings.  They are mainly helpful for package developers
or maintainers (who should be checking them).

If you are a Lisp-savvy user and you want to report a compiler warning
that you think might indicate a problem then, by all means, do let the
package maintainer know.  But most of the time users can and typically
should ignore byte-compiler warnings for 3rd-party packages, IMHO,
especially for packages that claim to support multiple Emacs versions.

A notable exception are undefined-variable warnings.  It is trivial
for a package maintainer to prevent an inappropriate undefined-variable
warning, no matter how old the Emacs versions supported by the package.
So if a user sees such a warning then yes, that is probably worth
reporting to the package maintainer.

And of course it is always OK to err on the side of caution and feel
free to report anything you see to a package maintainer.  My point is
only that users need not _worry_ just because they might see a bunch
of byte-compiler warnings.



  reply	other threads:[~2014-08-28 15:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 12:05 Flycheck reports are never satisfying!? Sebastien Vauban
2014-08-28 13:40 ` Stefan Monnier
2014-08-28 15:15   ` Sebastian Wiesner
2014-08-28 15:48     ` Stefan Monnier
2014-08-29  9:01       ` Sebastian Wiesner
2014-08-29 13:05         ` Stefan Monnier
     [not found]     ` <mailman.7732.1409240949.1147.help-gnu-emacs@gnu.org>
2014-08-28 17:35       ` Sebastien Vauban
2014-08-29  3:32         ` Stefan Monnier
     [not found] ` <mailman.7720.1409233288.1147.help-gnu-emacs@gnu.org>
2014-08-28 14:14   ` Sebastien Vauban
2014-08-28 14:38     ` Stefan Monnier
2014-08-28 15:51       ` Drew Adams [this message]
2014-08-28 15:25 ` Sebastian Wiesner
     [not found]   ` <61C65218-4004-4FD5-ABE0-6C863E5F60A6-MMJ3jE1zGgOaMJb+Lgu22Q@public.gmane.org>
2014-08-28 15:39     ` Sebastien Vauban
2014-08-28 15:45       ` Sebastian Wiesner
     [not found]         ` <B540BE8A-D03C-4F2D-ADB7-2A17F8E55F4E-MMJ3jE1zGgOaMJb+Lgu22Q@public.gmane.org>
2014-08-28 18:35           ` Sebastien Vauban
     [not found]         ` <mailman.7753.1409250970.1147.help-gnu-emacs@gnu.org>
     [not found]           ` <mailman.7753.1409250970.1147.help-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2014-09-01 10:00             ` Sebastien Vauban
2014-09-01 10:23               ` Sebastian Wiesner
2014-09-01 12:27 ` sokobania.01
2014-09-01 12:30 ` sokobania.01

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8aabfda9-fe74-43ee-92c6-51bf44ffb034@default \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.