[Top][All Lists]

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

Re: Flycheck reports are never satisfying!?

From: Stefan Monnier
Subject: Re: Flycheck reports are never satisfying!?
Date: Thu, 28 Aug 2014 10:38:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> Right. Though I'd think many, many packages still rely on others (and
> refer them). The first example that comes to my mind is Org that is
> based on Outline.

Indeed, packages aren't self-contained, but in most cases, when
a package uses another, it just `require's it, and the byte-compiler
knows about `require' and hence loads the corresponding file (i.e. runs
the `require' itself rather than only compiling it) before proceeding to
compile the rest of the file.

> Or "horizontal" packages called in many others, such
> as Helm or IDO...

In my experience, this is much less frequent, and is usually limited to
calling an (autoloaded) function.  The using-package may need a couple
of (defvar FOO) or (if (fboundp ...)) to avoid byte-compiler warnings, but
that's quite bearable.

For a .emacs, adding all the corresponding (defvar FOO) would be rather
annoying and would seem pointless.

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

> Still, I don't understand why my first example did return an error:
> there is an explicit call to a package which clearly is in `load-path',
> so why is the package reported as missing/unloadable?

You'll have to ask the flycheck author about that one, sadly.


reply via email to

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