Flycheck reports are never satisfying!?

Flycheck reports are never satisfying!?

[Sebastien Vauban]

Hello,

Trying to use, since short, Flycheck on all my prog modes; hence, on my
Emacs configuration file as well.

Though, as you can see on http://screencast.com/t/gfzLGy2h6fH, it never
is satisfying: there are always reports of errors or warnings, while my
code is completely clean (IMO).

Two ECM follow, showing what happens for all packages which I load and
customize.

    Note that, here, I took an extract from Flycheck's configuration
    itself, but the problem is the same with every third party
    package...

1. With an explicit package require:

--8<---------------cut here---------------start------------->8---
;;; .emacs-minimal.el --- Test file

;;; Commentary:

;;; Code:

(add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/")

(require 'flycheck)

;; modern on-the-fly syntax checking
(when (try-require 'flycheck)

  ;; indicate errors and warnings via icons in the left fringe
  (setq flycheck-indication-mode 'left-fringe)

  ;; enable Flycheck mode in all buffers
  (add-hook 'after-init-hook 'global-flycheck-mode))

(provide '.emacs-minimal)

;;; .emacs-minimal.el ends here
--8<---------------cut here---------------end--------------->8---

Flycheck reports one ERROR:

--8<---------------cut here---------------start------------->8---
    9   1 error    Cannot open load file: no such file or directory, flycheck (emacs-lisp)
--8<---------------cut here---------------end--------------->8---

2. With an implicit package require (call to function `try-require'):

--8<---------------cut here---------------start------------->8---
;;; .emacs-minimal2.el --- Test file

;;; Commentary:

;;; Internal function:

(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 "Missing package `%s'!" feature) nil)))

;;; Code:

(add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/")

;; modern on-the-fly syntax checking
(when (try-require 'flycheck)

  ;; indicate errors and warnings via icons in the left fringe
  (setq flycheck-indication-mode 'left-fringe)

  ;; enable Flycheck mode in all buffers
  (add-hook 'after-init-hook 'global-flycheck-mode))

(provide '.emacs-minimal2)

;;; .emacs-minimal2.el ends here
--8<---------------cut here---------------end--------------->8---

Flycheck reports one warning:

--8<---------------cut here---------------start------------->8---
   25   9 warning  assignment to free variable `flycheck-indication-mode' (emacs-lisp)
--8<---------------cut here---------------end--------------->8---

How am I supposed to do, if Flycheck reports things that shouldn't be
reported?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Flycheck reports are never satisfying!?

[Stefan Monnier]

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

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

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.

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


        Stefan

Re: Flycheck reports are never satisfying!?

[Sebastien Vauban]

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

Re: Flycheck reports are never satisfying!?

[Stefan Monnier]

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


        Stefan

Re: Flycheck reports are never satisfying!?

[Sebastian Wiesner]

Am 28.08.2014 um 15:40 schrieb Stefan Monnier <monnier@iro.umontreal.ca>:

>> --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.
> 
> And those packages are usually not loaded yet, because we want to load
> them lazily to speed up startup.
> 
> 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.
> 
> That's a problem I'd like to fix, but I'm not completely sure how.
> Suggestions welcome,

Isn’t that what we have „with-eval-after-load“ for?  At least, that’s what I am using in my init.el to avoid warnings about free variables.

Re: Flycheck reports are never satisfying!?

[Sebastian Wiesner]

Am 28.08.2014 um 14:05 schrieb Sebastien Vauban <sva-news@mygooglest.com>:

> Hello,
> 
> Trying to use, since short, Flycheck on all my prog modes; hence, on my
> Emacs configuration file as well.
> 
> Though, as you can see on http://screencast.com/t/gfzLGy2h6fH, it never
> is satisfying: there are always reports of errors or warnings, while my
> code is completely clean (IMO).

It’s not.  Flycheck runs the byte compiler on your init.el, and…

> Two ECM follow, showing what happens for all packages which I load and
> customize.
> 
>    Note that, here, I took an extract from Flycheck's configuration
>    itself, but the problem is the same with every third party
>    package...
> 
> 1. With an explicit package require:
> 
> --8<---------------cut here---------------start------------->8---
> ;;; .emacs-minimal.el --- Test file
> 
> ;;; Commentary:
> 
> ;;; Code:
> 
> (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/„)

…this expression is **not** evaluated by the byte compiler, so…

(in an unrelated note, this is a *very strange thing to do*.  The path suggests that you are using package.el to install Flycheck, but in that case you should *not* set up the load-path manual.  Instead call "(package-initialize)")

> (require ‚flycheck)

…when the byte compiler tries to evaluate this expression, Flycheck is not in your load-path, hence the error below.

Top-level "require"s are a special case.  The byte compiler evaluates these to load dependencies and macros, but it will **not** generally evaluated other expressions.


> ;; modern on-the-fly syntax checking
> (when (try-require 'flycheck)
> 
>  ;; indicate errors and warnings via icons in the left fringe
>  (setq flycheck-indication-mode 'left-fringe)
> 
>  ;; enable Flycheck mode in all buffers
>  (add-hook 'after-init-hook 'global-flycheck-mode))
> 
> (provide '.emacs-minimal)
> 
> ;;; .emacs-minimal.el ends here
> --8<---------------cut here---------------end--------------->8---
> 
> Flycheck reports one ERROR:
> 
> --8<---------------cut here---------------start------------->8---
>    9   1 error    Cannot open load file: no such file or directory, flycheck (emacs-lisp)
> --8<---------------cut here---------------end--------------->8---
> 
> 2. With an implicit package require (call to function `try-require'):
> 
> --8<---------------cut here---------------start------------->8---
> ;;; .emacs-minimal2.el --- Test file
> 
> ;;; Commentary:
> 
> ;;; Internal function:
> 
> (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 "Missing package `%s'!" feature) nil)))
> 
> ;;; Code:
> 
> (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/")
> 
> ;; modern on-the-fly syntax checking
> (when (try-require ‚flycheck)

As said above, the byte compiler doesn’t evaluate arbitrary expressions, and it doesn’t evaluate this call either.  Hence, it never attempts to actually load Flycheck, so there’s no error, but since Flycheck isn’t loaded, you get the warnings about free variables.

>  ;; indicate errors and warnings via icons in the left fringe
>  (setq flycheck-indication-mode 'left-fringe)
> 
>  ;; enable Flycheck mode in all buffers
>  (add-hook 'after-init-hook 'global-flycheck-mode))
> 
> (provide '.emacs-minimal2)
> 
> ;;; .emacs-minimal2.el ends here
> --8<---------------cut here---------------end--------------->8---
> 
> Flycheck reports one warning:
> 
> --8<---------------cut here---------------start------------->8---
>   25   9 warning  assignment to free variable `flycheck-indication-mode' (emacs-lisp)
> --8<---------------cut here---------------end--------------->8---
> 
> How am I supposed to do, if Flycheck reports things that shouldn't be
> reported?

Generally, you should set the corresponding options of the "emacs-lisp" syntax checker [1] to set the "load-path" for Flycheck, or enable "package.el" for Flycheck.

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, so please open an issue in Flycheck's issue tracker at https://github.com/flycheck/flycheck/issues

[1]: http://flycheck.readthedocs.org/en/latest/guide/languages.html#el.flycheck-checker.emacs-lisp

Re: Flycheck reports are never satisfying!?

[Sebastien Vauban]

Hello Sebastian,

Sebastian Wiesner wrote:
> Am 28.08.2014 um 14:05 schrieb Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>:
>
>> Trying to use, since short, Flycheck on all my prog modes; hence, on my
>> Emacs configuration file as well.
>> 
>> Though, as you can see on http://screencast.com/t/gfzLGy2h6fH, it never
>> is satisfying: there are always reports of errors or warnings, while my
>> code is completely clean (IMO).
>
> It’s not.  Flycheck runs the byte compiler on your init.el, and…
>
>> Two ECM follow, showing what happens for all packages which I load and
>> customize.
>> 
>>    Note that, here, I took an extract from Flycheck's configuration
>>    itself, but the problem is the same with every third party
>>    package...
>> 
>> 1. With an explicit package require:
>> 
>> --8<---------------cut here---------------start------------->8---
>> ;;; .emacs-minimal.el --- Test file
>> 
>> ;;; Commentary:
>> 
>> ;;; Code:
>> 
>> (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/„)
>
> …this expression is **not** evaluated by the byte compiler, so…

Anything to do about this?

> (in an unrelated note, this is a *very strange thing to do*.  The path suggests
> that you are using package.el to install Flycheck, but in that case you should
> *not* set up the load-path manual.  Instead call "(package-initialize)")

I know package, and I'm using it.

Here, in an ECM ("Minimal Working Example", in French), I've added that
line to my .emacs to really show that the path was correctly set up.

In my real example, I just have a call to package-initialize (in some
GNUEmacs macro, though) but I have the same problems about free
variables.

I added explicit require's to be sure as well that packages were
loaded. But, as you say...

>> (require ‚flycheck)
>
> …when the byte compiler tries to evaluate this expression, Flycheck is not in
> your load-path, hence the error below.

... if the path is not updated, it never will find the packages...

> Top-level "require"s are a special case.  The byte compiler evaluates these to
> load dependencies and macros, but it will **not** generally evaluated other
> expressions.

And many parts of my .emacs are in macros such as RunningWindows,
GNUEmacs, RunningCygwinVersion, etc.

>> ;; modern on-the-fly syntax checking
>> (when (try-require 'flycheck)
>> 
>>  ;; indicate errors and warnings via icons in the left fringe
>>  (setq flycheck-indication-mode 'left-fringe)
>> 
>>  ;; enable Flycheck mode in all buffers
>>  (add-hook 'after-init-hook 'global-flycheck-mode))
>> 
>> (provide '.emacs-minimal)
>> 
>> ;;; .emacs-minimal.el ends here
>> --8<---------------cut here---------------end--------------->8---
>> 
>> Flycheck reports one ERROR:
>> 
>> --8<---------------cut here---------------start------------->8---
>>    9   1 error    Cannot open load file: no such file or directory, flycheck (emacs-lisp)
>> --8<---------------cut here---------------end--------------->8---
>> 
>> 2. With an implicit package require (call to function `try-require'):
>> 
>> --8<---------------cut here---------------start------------->8---
>> ;;; .emacs-minimal2.el --- Test file
>> 
>> ;;; Commentary:
>> 
>> ;;; Internal function:
>> 
>> (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 "Missing package `%s'!" feature) nil)))
>> 
>> ;;; Code:
>> 
>> (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/")
>> 
>> ;; modern on-the-fly syntax checking
>> (when (try-require ‚flycheck)
>
> As said above, the byte compiler doesn’t evaluate arbitrary expressions, and it
> doesn’t evaluate this call either.  Hence, it never attempts to actually load
> Flycheck, so there’s no error, but since Flycheck isn’t loaded, you get the
> warnings about free variables.
>
>>  ;; indicate errors and warnings via icons in the left fringe
>>  (setq flycheck-indication-mode 'left-fringe)
>> 
>>  ;; enable Flycheck mode in all buffers
>>  (add-hook 'after-init-hook 'global-flycheck-mode))
>> 
>> (provide '.emacs-minimal2)
>> 
>> ;;; .emacs-minimal2.el ends here
>> --8<---------------cut here---------------end--------------->8---
>> 
>> Flycheck reports one warning:
>> 
>> --8<---------------cut here---------------start------------->8---
>>   25   9 warning  assignment to free variable `flycheck-indication-mode' (emacs-lisp)
>> --8<---------------cut here---------------end--------------->8---
>> 
>> How am I supposed to do, if Flycheck reports things that shouldn't be
>> reported?
>
> Generally, you should set the corresponding options of the "emacs-lisp" syntax
> checker [1] to set the "load-path" for Flycheck, or enable "package.el" for
> Flycheck.
>
> 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, so please open an
> issue in Flycheck's issue tracker at https://github.com/flycheck/flycheck/issues

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,
which is of course much bigger.

This particularity can explain that package is not enabled, right?

> [1]: http://flycheck.readthedocs.org/en/latest/guide/languages.html#el.flycheck-checker.emacs-lisp

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Flycheck reports are never satisfying!?

[Sebastian Wiesner]

Am 28.08.2014 um 17:39 schrieb Sebastien Vauban <sva-news@mygooglest.com>:

> Hello Sebastian,
> 
> Sebastian Wiesner wrote:
>> Am 28.08.2014 um 14:05 schrieb Sebastien Vauban <sva-news@mygooglest.com>:
>> 
>>> Trying to use, since short, Flycheck on all my prog modes; hence, on my
>>> Emacs configuration file as well.
>>> 
>>> Though, as you can see on http://screencast.com/t/gfzLGy2h6fH, it never
>>> is satisfying: there are always reports of errors or warnings, while my
>>> code is completely clean (IMO).
>> 
>> It’s not.  Flycheck runs the byte compiler on your init.el, and…
>> 
>>> Two ECM follow, showing what happens for all packages which I load and
>>> customize.
>>> 
>>>   Note that, here, I took an extract from Flycheck's configuration
>>>   itself, but the problem is the same with every third party
>>>   package...
>>> 
>>> 1. With an explicit package require:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>> ;;; .emacs-minimal.el --- Test file
>>> 
>>> ;;; Commentary:
>>> 
>>> ;;; Code:
>>> 
>>> (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/„)
>> 
>> …this expression is **not** evaluated by the byte compiler, so…
> 
> Anything to do about this?

eval-and-compile

> 
>> (in an unrelated note, this is a *very strange thing to do*.  The path suggests
>> that you are using package.el to install Flycheck, but in that case you should
>> *not* set up the load-path manual.  Instead call "(package-initialize)")
> 
> I know package, and I'm using it.
> 
> Here, in an ECM ("Minimal Working Example", in French), I've added that
> line to my .emacs to really show that the path was correctly set up.

I found that confusing.
> 
>> Top-level "require"s are a special case.  The byte compiler evaluates these to
>> load dependencies and macros, but it will **not** generally evaluated other
>> expressions.
> 
> And many parts of my .emacs are in macros such as RunningWindows,
> GNUEmacs, RunningCygwinVersion, etc.
> 
>>> ;; modern on-the-fly syntax checking
>>> (when (try-require 'flycheck)
>>> 
>>> ;; indicate errors and warnings via icons in the left fringe
>>> (setq flycheck-indication-mode 'left-fringe)
>>> 
>>> ;; enable Flycheck mode in all buffers
>>> (add-hook 'after-init-hook 'global-flycheck-mode))
>>> 
>>> (provide '.emacs-minimal)
>>> 
>>> ;;; .emacs-minimal.el ends here
>>> --8<---------------cut here---------------end--------------->8---
>>> 
>>> Flycheck reports one ERROR:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>>   9   1 error    Cannot open load file: no such file or directory, flycheck (emacs-lisp)
>>> --8<---------------cut here---------------end--------------->8---
>>> 
>>> 2. With an implicit package require (call to function `try-require'):
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>> ;;; .emacs-minimal2.el --- Test file
>>> 
>>> ;;; Commentary:
>>> 
>>> ;;; Internal function:
>>> 
>>> (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 "Missing package `%s'!" feature) nil)))
>>> 
>>> ;;; Code:
>>> 
>>> (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/")
>>> 
>>> ;; modern on-the-fly syntax checking
>>> (when (try-require ‚flycheck)
>> 
>> As said above, the byte compiler doesn’t evaluate arbitrary expressions, and it
>> doesn’t evaluate this call either.  Hence, it never attempts to actually load
>> Flycheck, so there’s no error, but since Flycheck isn’t loaded, you get the
>> warnings about free variables.
>> 
>>> ;; indicate errors and warnings via icons in the left fringe
>>> (setq flycheck-indication-mode 'left-fringe)
>>> 
>>> ;; enable Flycheck mode in all buffers
>>> (add-hook 'after-init-hook 'global-flycheck-mode))
>>> 
>>> (provide '.emacs-minimal2)
>>> 
>>> ;;; .emacs-minimal2.el ends here
>>> --8<---------------cut here---------------end--------------->8---
>>> 
>>> Flycheck reports one warning:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>>  25   9 warning  assignment to free variable `flycheck-indication-mode' (emacs-lisp)
>>> --8<---------------cut here---------------end--------------->8---
>>> 
>>> How am I supposed to do, if Flycheck reports things that shouldn't be
>>> reported?
>> 
>> Generally, you should set the corresponding options of the "emacs-lisp" syntax
>> checker [1] to set the "load-path" for Flycheck, or enable "package.el" for
>> Flycheck.
>> 
>> 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, so please open an
>> issue in Flycheck's issue tracker at https://github.com/flycheck/flycheck/issues
> 
> 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,
> which is of course much bigger.
> 
> This particularity can explain that package is not enabled, right?

I presume that this “shared” file is not in "~/.emacs.d/", is it?  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.

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.

> 
>> [1]: http://flycheck.readthedocs.org/en/latest/guide/languages.html#el.flycheck-checker.emacs-lisp
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban

Re: Flycheck reports are never satisfying!?

[Stefan Monnier]

> Isn’t that what we have „with-eval-after-load“ for?

with-eval-after-load is there to help make startup more lazy.  But it's
not particularly designed to help silence "spurious" byte-compiler warnings.

> At least, that’s what I am using in my init.el to avoid warnings about
> free variables.

I'm surprised it works for you.

This said, maybe the byte-compiler should treat it specially
(i.e. treat it sort of like a `require' and forcefully load the file
before processing the body of the with-eval-after-load).


        Stefan

worrying about byte-compiler warnings [was: Flycheck reports are never satisfying!?]

[Drew Adams]

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

Re: Flycheck reports are never satisfying!?

[Sebastien Vauban]

Stefan Monnier wrote:
>> Isn’t that what we have „with-eval-after-load“ for?
>
> with-eval-after-load is there to help make startup more lazy.  But it's
> not particularly designed to help silence "spurious" byte-compiler warnings.
>
> This said, maybe the byte-compiler should treat it specially
> (i.e. treat it sort of like a `require' and forcefully load the file
> before processing the body of the with-eval-after-load).

That would make a lot of sense, IMHO.

And for personal constructions such as:

--8<---------------cut here---------------start------------->8---
(when (try-require 'blah)
  ...)
--8<---------------cut here---------------end--------------->8---

Would there be a solution?

Would replacing `try-require' by a `require' with all the necessary
parameters (in order not to stop if the package is missing) be OK?

--8<---------------cut here---------------start------------->8---
(when (require 'blah nil t)
  ...)
--8<---------------cut here---------------end--------------->8---

Would this last construct work?  If yes, I'm willing to use it instead
of my `try-require'...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Flycheck reports are never satisfying!?

[Sebastien Vauban]

Hallo Sebastian,

Sebastian Wiesner wrote:
> Am 28.08.2014 um 17:39 schrieb Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>:
>> 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, so please open an issue in Flycheck's
>>> issue tracker at https://github.com/flycheck/flycheck/issues
>> 
>> 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,
>> which is of course much bigger.
>> 
>> This particularity can explain that package is not enabled, right?
>
> I presume that this “shared” file is not in "~/.emacs.d/", is it?  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.
>
> 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.

I just tested this, on another MWE:

--8<---------------cut here---------------start------------->8---
;;; .emacs-minimal.el --- Test file

;;; Commentary:

;;; Code:

(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)))

(when (require 'idle-require nil t)
  (setq idle-require-idle-delay 5)
  (setq idle-require-load-break 2))

(when (try-require 'idle-require)
  (setq idle-require-idle-delay 5)
  (setq idle-require-load-break 2))

(provide '.emacs-minimal)

;; This is for the sake of Emacs.
;; Local Variables:
;; flycheck-emacs-lisp-initialize-packages: t
;; flyspell-mode: nil
;; End:

;;; .emacs-minimal.el ends here
--8<---------------cut here---------------end--------------->8---

See the results on http://screencast.com/t/bnfoDJqBX:

- I still have the variables from the package `idle-require' reported as
  unknown...

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

Best regards,
  Seb

PS- A funny thing (?) is that only the first occurrence of the variable
    is reported as unknown.

-- 
Sebastien Vauban

Re: Flycheck reports are never satisfying!?

[Stefan Monnier]

> That would make a lot of sense, IMHO.

I could consider inclusion of such a patch.

> --8<---------------cut here---------------start------------->8---
> (when (try-require 'blah)
>   ...)
> --8<---------------cut here---------------end--------------->8---
> Would there be a solution?

No, the compiler doesn't know anything about try-require.

> Would replacing `try-require' by a `require' with all the necessary
> parameters (in order not to stop if the package is missing) be OK?
> --8<---------------cut here---------------start------------->8---
> (when (require 'blah nil t)
>   ...)
> --8<---------------cut here---------------end--------------->8---
> Would this last construct work?  If yes, I'm willing to use it instead
> of my `try-require'...

Maybe we could make it work, yes.

Still, there's a problem: one of the reasons to try and byte-compile the
.emacs file is so as to give warnings to the user about use of obsolete
variables and functions.

But for that to work well (i.e. used all the time by default),
byte-compilation should be quick and lightweight.

But that won't work if we start pre-loading eagerly all those packages
that the user is painstaking trying to load lazily.

I have this nagging feeling that we can't make it work by just
byte-compiling the .emacs in the same way as any other Elisp package.
Maybe rather than re-using the byte-compiler's warnings, we really need
a specialized tool for that.


        Stefan

Re: Flycheck reports are never satisfying!?

[Sebastian Wiesner]

Am 28.08.2014 um 17:48 schrieb Stefan Monnier <monnier@iro.umontreal.ca>:

>> Isn’t that what we have „with-eval-after-load“ for?
> 
> with-eval-after-load is there to help make startup more lazy.  But it's
> not particularly designed to help silence "spurious" byte-compiler warnings.
> 
>> At least, that’s what I am using in my init.el to avoid warnings about
>> free variables.
> 
> I'm surprised it works for you.

I'm sorry, it doesn't, of course.  I mistakenly assumed that with-eval-after-load did that, but actually I'm using my own macro on top of with-eval-after-load that requires the given feature during byte compilation.  I forgot about that.

Please excuse the confusion.

> 
> This said, maybe the byte-compiler should treat it specially
> (i.e. treat it sort of like a `require' and forcefully load the file
> before processing the body of the with-eval-after-load).

Couldn't with-eval-after-load just require the feature if byte-compile-current-file is non-nil?

At least, that's what I am doing in my own macro, and it works reasonably well.

Re: Flycheck reports are never satisfying!?

[Stefan Monnier]

>> This said, maybe the byte-compiler should treat it specially
>> (i.e. treat it sort of like a `require' and forcefully load the file
>> before processing the body of the with-eval-after-load).
> Couldn't with-eval-after-load just require the feature if
> byte-compile-current-file is non-nil?

It could, of course.  The cleaner way is to add an entry in
byte-compile-macro-environment, tho.


        Stefan

Re: Flycheck reports are never satisfying!?

[Sebastien Vauban]

Hallo Sebastian,

Sebastien Vauban wrote:
> Sebastian Wiesner wrote:
>> Am 28.08.2014 um 17:39 schrieb Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>:
>>> 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.
>>>
>>> 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.
>>>
>>> This particularity can explain that package is not enabled, right?
>>
>> I presume that this “shared” file is not in "~/.emacs.d/", is it?

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.
>>
>> 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.
>
> I just tested this, on another MWE:
>
> ;;; .emacs-minimal.el --- Test file
>
> ;;; Commentary:
>
> ;;; Code:
>
> (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)))
>
> (when (require 'idle-require nil t)
>   (setq idle-require-idle-delay 5)
>   (setq idle-require-load-break 2))
>
> (when (try-require 'idle-require)
>   (setq idle-require-idle-delay 5)
>   (setq idle-require-load-break 2))
>
> (provide '.emacs-minimal)
>
> ;; This is for the sake of Emacs.
> ;; Local Variables:
> ;; flycheck-emacs-lisp-initialize-packages: t
> ;; flyspell-mode: nil
> ;; End:
>
> ;;; .emacs-minimal.el ends here
>
> See the results on http://screencast.com/t/bnfoDJqBX:
>
> - I still have the variables from the package `idle-require' reported as
>   unknown...
>
> - 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'.

Any idea why the local var `flycheck-emacs-lisp-initialize-packages'
seems to have no effect?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Flycheck reports are never satisfying!?

[Sebastian Wiesner]

Am 01.09.2014 um 12:00 schrieb Sebastien Vauban <sva-news@mygooglest.com>:

> Hallo Sebastian,
> 
> Sebastien Vauban wrote:
>> Sebastian Wiesner wrote:
>>> Am 28.08.2014 um 17:39 schrieb Sebastien Vauban <sva-news@mygooglest.com>:
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> This particularity can explain that package is not enabled, right?
>>> 
>>> I presume that this “shared” file is not in "~/.emacs.d/", is it?
> 
> 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.
>>> 
>>> 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.
>> 
>> I just tested this, on another MWE:
>> 
>> ;;; .emacs-minimal.el --- Test file
>> 
>> ;;; Commentary:
>> 
>> ;;; Code:
>> 
>> (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)))
>> 
>> (when (require 'idle-require nil t)
>>  (setq idle-require-idle-delay 5)
>>  (setq idle-require-load-break 2))
>> 
>> (when (try-require 'idle-require)
>>  (setq idle-require-idle-delay 5)
>>  (setq idle-require-load-break 2))
>> 
>> (provide '.emacs-minimal)
>> 
>> ;; This is for the sake of Emacs.
>> ;; Local Variables:
>> ;; flycheck-emacs-lisp-initialize-packages: t
>> ;; flyspell-mode: nil
>> ;; End:
>> 
>> ;;; .emacs-minimal.el ends here
>> 
>> See the results on http://screencast.com/t/bnfoDJqBX:
>> 
>> - I still have the variables from the package `idle-require' reported as
>>  unknown...
>> 
>> - 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'.
> 
> 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'. 

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

Re: Flycheck reports are never satisfying!?

[sokobania.01]

What about just putting something like this:

(eval-when (compile) (require 'flycheck))

Shouldn't it require and load the flycheck module only at compile time?

Re: Flycheck reports are never satisfying!?

[sokobania.01]

What about just putting something like this:

(eval-when (compile)
  (let ((load-path load-path))
    (add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20140824.731/") 
    (require 'flycheck)))

Shouldn't it require and load the flycheck module only at compile time?