From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sebastien Vauban Newsgroups: gmane.emacs.help Subject: Re: Flycheck reports are never satisfying!? Date: Thu, 28 Aug 2014 16:14:17 +0200 Organization: Sebastien Vauban Message-ID: <86bnr4ya4m.fsf@somewhere.org> References: <86ha0w95vp.fsf@somewhere.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1409235596 3393 80.91.229.3 (28 Aug 2014 14:19:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2014 14:19:56 +0000 (UTC) To: help-gnu-emacs-mXXj517/zsQ@public.gmane.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Thu Aug 28 16:19:50 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XN0Y9-0001mP-Os for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Aug 2014 16:19:41 +0200 Original-Received: from localhost ([::1]:36849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XN0Y9-0000TV-6Z for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Aug 2014 10:19:41 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 59 Injection-Info: mx05.eternal-september.org; posting-host="402b34550bd938aa98825778083dce0e"; logging-data="2611"; mail-complaints-to="abuse-VVbKFVtnif8H+i2N2EyTrmui9UKz+5OX@public.gmane.org"; posting-account="U2FsdGVkX1+JpjmGHAARmzytNM6c0cZQ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) X-Archive: encrypt Cancel-Lock: sha1:jdG9XGAabcP0chURpJixcA+yTfo= sha1:YRqUfbi0yWgJGBrH6MsUf17wBXo= X-Url: Under construction... Original-Xref: usenet.stanford.edu gnu.emacs.help:207187 X-BeenThere: help-gnu-emacs-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.emacs.help:99463 Archived-At: 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 "") '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