From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sebastian Wiesner Newsgroups: gmane.emacs.help Subject: Re: Flycheck reports are never satisfying!? Date: Mon, 1 Sep 2014 12:23:21 +0200 Message-ID: <814CFCAE-EA3C-4C92-889F-20A247A13AA1@lunaryorn.com> References: <86ha0w95vp.fsf@somewhere.org> <61C65218-4004-4FD5-ABE0-6C863E5F60A6@lunaryorn.com> <86bnr4wrmh.fsf@somewhere.org> <86oauzhd9a.fsf@somewhere.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1409567031 12538 80.91.229.3 (1 Sep 2014 10:23:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2014 10:23:51 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Sebastien Vauban Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Sep 01 12:23:45 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 1XOOm0-0008RX-Ho for geh-help-gnu-emacs@m.gmane.org; Mon, 01 Sep 2014 12:23:44 +0200 Original-Received: from localhost ([::1]:59167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOOm0-0002Ei-1n for geh-help-gnu-emacs@m.gmane.org; Mon, 01 Sep 2014 06:23:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOOll-0002Dr-Ne for help-gnu-emacs@gnu.org; Mon, 01 Sep 2014 06:23:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOOlh-0006af-Is for help-gnu-emacs@gnu.org; Mon, 01 Sep 2014 06:23:29 -0400 Original-Received: from vega.uberspace.de ([95.143.172.245]:57018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOOlh-0006aW-9H for help-gnu-emacs@gnu.org; Mon, 01 Sep 2014 06:23:25 -0400 Original-Received: (qmail 12830 invoked from network); 1 Sep 2014 10:23:23 -0000 Original-Received: from localhost (HELO 17.196.eduroam.dynamic.rbg.tum.de) (127.0.0.1) by vega.uberspace.de with SMTP; 1 Sep 2014 10:23:23 -0000 In-Reply-To: <86oauzhd9a.fsf@somewhere.org> X-Mailer: Apple Mail (2.1878.6) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 95.143.172.245 X-BeenThere: help-gnu-emacs@gnu.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@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:99558 Archived-At: Am 01.09.2014 um 12:00 schrieb Sebastien Vauban = : > Hallo Sebastian, >=20 > Sebastien Vauban wrote: >> Sebastian Wiesner wrote: >>> Am 28.08.2014 um 17:39 schrieb Sebastien Vauban = : >>>> Sebastian Wiesner wrote: >>>>> However, as far as "init.el" is concerned, Flycheck should >>>>> automatically enable package.el for syntax checking. This doesn't >>>>> seem to work in your case, and indicates that there is something >>>>> unusual about your setup. >>>>=20 >>>> In my case, in fact, my init.el is just a stub with my really = really >>>> personal settings. It calls another file with more general = settings, >>>> which I share with colleagues. All my problems are in this last = file. >>>>=20 >>>> This particularity can explain that package is not enabled, right? >>>=20 >>> I presume that this =93shared=94 file is not in "~/.emacs.d/", is = it? >=20 > Right. >>> In that case, Flycheck can't know that it's part of your Emacs >>> configuration, and treats it as if it were any random Emacs Lisp >>> file, which means that packages aren't enabled. >>>=20 >>> Add "flycheck-emacs-lisp-initialize-packages" to the file-local >>> variables of that file, with a value of t. This forces Flycheck to >>> enable packages when checking the file. >>=20 >> I just tested this, on another MWE: >>=20 >> ;;; .emacs-minimal.el --- Test file >>=20 >> ;;; Commentary: >>=20 >> ;;; Code: >>=20 >> (defun try-require (feature) >> "Attempt to load a FEATURE (or library). >> Return true if the library given as argument is successfully loaded. = If >> not, just print a message." >> (condition-case err >> (progn (if (stringp feature) >> (load-library feature) >> (require feature)) t) >> (file-error (message "Requiring `%s'... missing" feature) nil))) >>=20 >> (when (require 'idle-require nil t) >> (setq idle-require-idle-delay 5) >> (setq idle-require-load-break 2)) >>=20 >> (when (try-require 'idle-require) >> (setq idle-require-idle-delay 5) >> (setq idle-require-load-break 2)) >>=20 >> (provide '.emacs-minimal) >>=20 >> ;; This is for the sake of Emacs. >> ;; Local Variables: >> ;; flycheck-emacs-lisp-initialize-packages: t >> ;; flyspell-mode: nil >> ;; End: >>=20 >> ;;; .emacs-minimal.el ends here >>=20 >> See the results on http://screencast.com/t/bnfoDJqBX: >>=20 >> - I still have the variables from the package `idle-require' reported = as >> unknown... >>=20 >> - while that's a package which is under ELPA (right now in >> ~/.emacs.d/elpa/idle-require-20090716.3/) and I do have >> `flycheck-emacs-lisp-initialize-packages' set to `t'. >=20 > Any idea why the local var `flycheck-emacs-lisp-initialize-packages' > seems to have no effect? The variable does have the intended effect: The package system is = initialized and the package is placed in `load-path'.=20 But it's still not loaded, because neither `require' nor `try-require' = are ever called during compilation. As said before, only *top-level* `require' forms are evaluated by the = byte compiler. Your `try-require' is a `require' form, obviously, and = your `require' call isn't top-level, since it's wrapped in `when'. The = byte compiler just treats these like any other expression, and compiles = them to byte code without evaluating them first. You'll either have to `require' the package at *top-level*, or use = `eval-when-compile'/`eval-and-compile' at the appropriate places to = force the byte compiler to load your package during byte compilation. For customization purposes specifically, you may use the following = macro: (defmacro lunaryorn-after (feature &rest forms) (declare (indent 1) (debug t)) (when (bound-and-true-p byte-compile-current-file) (message "LOADING") (if (stringp feature) (load feature nil 'no-error) (require feature nil 'no-error))) `(with-eval-after-load ',feature ,@forms)) It's lazy like `with-eval-after-load', that is, delays the body until = after the feature is loaded, but requires the feature during compilation = to make variable definitions available. Use it like this: (lunaryorn-after idle-require (setq idle-require-idle-delay 5 idle-require-load-break 2)) You'll need Emacs 24.4 for `with-eval-after-load`, or copy the = definition of `with-eval-after-load' for earlier Emacsen. See = http://www.lunaryorn.com/2013/06/25/introducing-with-eval-after-load.html=