help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Flycheck reports are never satisfying!?


From: Sebastien Vauban
Subject: Re: Flycheck reports are never satisfying!?
Date: Thu, 28 Aug 2014 16:14:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt)

Hello Stefan,

Stefan Monnier wrote:
>> --8<---------------cut here---------------start------------->8---
>>    25   9 warning  assignment to free variable `flycheck-indication-mode' 
>> (emacs-lisp)
>> --8<---------------cut here---------------end--------------->8---
>
> The .emacs file is very much unlike a normal Elisp package: instead of
> defining its own functions/command/variables and exporting them for
> use, it normally does mostly things like modifying other package's
> variables.

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. Or "horizontal" packages called in many others, such
as Helm or IDO...

In such cases, the packages (which use "externals") will output as many
warnings as well, for references to "undefined variables"?

> And those packages are usually not loaded yet, because we want to load
> them lazily to speed up startup.

Right. That's why my preferred solution to write things in my .emacs is
something along these lines:

--8<---------------cut here---------------start------------->8---
  (global-set-key (kbd "<key>") 'some-pkg-fun-foo)

  (with-eval-after-load "some-pkg"
    (setq some-pkg-var-1 "bar")
    (some-pkg-fun-baz))
--8<---------------cut here---------------end--------------->8---

or (for not-heavy packages):

--8<---------------cut here---------------start------------->8---
  (when (try-require 'some-pkg)
    (setq some-pkg-var-1 "bar")
    (some-pkg-fun-baz)
    ...)
--8<---------------cut here---------------end--------------->8---

> So yes, if you try to byte-compile your .emacs chances are the
> byte-compiler will give you lots and lots of warnings about
> assignments or references to free variables.

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?

> That's a problem I'd like to fix, but I'm not completely sure how.
> Suggestions welcome,

Best regards,
  Seb

-- 
Sebastien Vauban


reply via email to

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