GNU bug report logs - #55811
29.0.50; No flymake diagnostics for no-byte-compile files

Previous Next

To reply to this bug, email your comments to 55811 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; No flymake diagnostics for no-byte-compile files
Date: Sun, 05 Jun 2022 16:22:49 -0400

Package: Emacs
Version: 29.0.50


As the title says, if you enable `flymake-mode` in an ELisp file with
a `no-byte-compile: t` in its file-local variables you don't get any
diagnostics from the compiler (you do still get diagnostics from
checkdoc, admittedly).

I think `no-byte-compile` only means that we should load the `.el` file
and not generate a `.elc` file and it shouldn't mean that we should
refrain from asking the byte-compiler what is its opinion about the
quality of this code.


        Stefan



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2022-05-27 built on pastel
Repository revision: 0217902f8b8f1611fec87f4874edbbf485120f9b
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable
 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign'
 PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
THREADS TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: fr_CH.UTF-8
  locale-coding-system: utf-8-unix

Major mode: InactiveMinibuffer

Minor modes in effect:
  csv-field-index-mode: t
  shell-dirtrack-mode: t
  server-mode: t
  electric-pair-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  global-compact-docstrings-mode: t
  url-handler-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  global-prettify-symbols-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/monnier/src/emacs/nongnu/packages/geiser-kawa/geiser-kawa-autoloads hides /home/monnier/src/emacs/nongnu/packages/geiser-kawa/elisp/geiser-kawa-autoloads
/home/monnier/src/emacs/nongnu/packages/geiser/geiser-autoloads hides /home/monnier/src/emacs/nongnu/packages/geiser/elisp/geiser-autoloads
/home/monnier/src/emacs/nongnu/packages/arduino-mode/ob-arduino hides /home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ob-arduino
/home/monnier/src/emacs/nongnu/packages/org-contrib/org-contrib-autoloads hides /home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/org-contrib-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/magit-section-pkg hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-section-pkg
/home/monnier/src/emacs/nongnu/packages/magit/git-commit-autoloads hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/git-commit-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/magit-pkg hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-pkg
/home/monnier/src/emacs/nongnu/packages/magit/git-commit-pkg hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/git-commit-pkg
/home/monnier/src/emacs/nongnu/packages/magit/magit-section-autoloads hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-section-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/magit-autoloads hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-autoloads
/home/monnier/src/emacs/nongnu/packages/pdf-tools/pdf-tools-autoloads hides /home/monnier/src/emacs/nongnu/packages/pdf-tools/lisp/pdf-tools-autoloads
/home/monnier/src/emacs/nongnu/packages/php-mode/php-mode-autoloads hides /home/monnier/src/emacs/nongnu/packages/php-mode/lisp/php-mode-autoloads
/home/monnier/src/emacs/nongnu/packages/jade-mode/sws-mode hides /home/monnier/src/emacs/nongnu/packages/stylus-mode/sws-mode
/home/monnier/src/emacs/nongnu/packages/jade-mode/jade-mode hides /home/monnier/src/emacs/nongnu/packages/stylus-mode/jade-mode
/home/monnier/src/emacs/nongnu/packages/jade-mode/stylus-mode hides /home/monnier/src/emacs/nongnu/packages/stylus-mode/stylus-mode
/home/monnier/src/emacs/nongnu/packages/subed/subed-autoloads hides /home/monnier/src/emacs/nongnu/packages/subed/subed/subed-autoloads
/home/monnier/src/emacs/nongnu/packages/with-editor/with-editor-autoloads hides /home/monnier/src/emacs/nongnu/packages/with-editor/lisp/with-editor-autoloads
/home/monnier/src/emacs/elpa/packages/bbdb/bbdb-autoloads hides /home/monnier/src/emacs/elpa/packages/bbdb/lisp/bbdb-autoloads
/home/monnier/src/emacs/nongnu/packages/paredit/test hides /home/monnier/src/emacs/elpa/packages/easy-kill/test
/home/monnier/src/emacs/elpa/packages/emacspeak/emacspeak-autoloads hides /home/monnier/src/emacs/elpa/packages/emacspeak/lisp/emacspeak-autoloads
/home/monnier/src/emacs/elpa/packages/embark-consult/embark-consult hides /home/monnier/src/emacs/elpa/packages/embark/embark-consult
/home/monnier/src/emacs/elpa/packages/embark-consult/embark hides /home/monnier/src/emacs/elpa/packages/embark/embark
/home/monnier/src/emacs/elpa/packages/embark-consult/embark-org hides /home/monnier/src/emacs/elpa/packages/embark/embark-org
/home/monnier/src/emacs/elpa/packages/embark-consult/avy-embark-collect hides /home/monnier/src/emacs/elpa/packages/embark/avy-embark-collect
/home/monnier/src/emacs/nongnu/packages/paredit/test hides /home/monnier/src/emacs/elpa/packages/pq/test
/home/monnier/src/emacs/elpa/packages/realgud-lldb/cask-install hides /home/monnier/src/emacs/elpa/packages/realgud-trepan-ni/cask-install
/home/monnier/src/emacs/elpa/packages/realgud-lldb/cask-install hides /home/monnier/src/emacs/elpa/packages/realgud/cask-install
/home/monnier/src/emacs/elpa/packages/srht/srht-autoloads hides /home/monnier/src/emacs/elpa/packages/srht/lisp/srht-autoloads
/home/monnier/src/emacs/elpa/packages/taxy/taxy-magit-section hides /home/monnier/src/emacs/elpa/packages/taxy-magit-section/taxy-magit-section
/home/monnier/src/emacs/elpa/packages/transient/transient-autoloads hides /home/monnier/src/emacs/elpa/packages/transient/lisp/transient-autoloads
/home/monnier/src/emacs/elpa/packages/transient/lisp/transient hides /home/monnier/src/emacs/work/lisp/transient
/home/monnier/src/emacs/nongnu/packages/lua-mode/lua-mode hides /home/monnier/src/emacs/work/lisp/progmodes/lua-mode
/home/monnier/src/emacs/elpa/packages/emacspeak/lisp/tetris hides /home/monnier/src/emacs/work/lisp/play/tetris
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ox-koma-letter hides /home/monnier/src/emacs/work/lisp/org/ox-koma-letter
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ol-man hides /home/monnier/src/emacs/work/lisp/org/ol-man
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ob-julia hides /home/monnier/src/emacs/work/lisp/org/ob-julia
/home/monnier/src/emacs/work/lisp/keymap hides /home/monnier/src/emacs/work/lisp/emacs-lisp/keymap
/home/monnier/.emacs.d/elpa/hyperbole-8.0.0/set hides /home/monnier/src/emacs/work/lisp/emacs-lisp/set
/home/monnier/src/emacs/elpa/packages/crisp/crisp hides /home/monnier/src/emacs/work/lisp/obsolete/crisp
/home/monnier/src/emacs/elpa/packages/landmark/landmark hides /home/monnier/src/emacs/work/lisp/obsolete/landmark

Features:
(sml-mode emms-source-file locate emms emms-compat eev-wrap
eev-template0 eev-env eepitch eev-multiwindow ielm buttercup ert
buttercup-compat descr-text csv-mode beancount cus-edit cus-start
cus-load autoconf autoconf-mode sh-script epa-file bindat markdown-mode
bbdb-com bbdb bbdb-site timezone make-mode rfc2104 mailalias smtpmail
textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check pp shadow sort mail-extr emacsbug rect sm-c-mode
drupal/emacs-drush drupal/etags etags fileloop xref reposition
mm-archive url-dav url-http-ntlm ntlm hmac-md5 hex-util md4
network-stream url-cache url-http url-gw nsm reftex-ref reftex-cite
reftex-parse dabbrev tuareg speedbar imenu ezimage dframe skeleton
tuareg-compat tuareg-opam smie caml-types caml-help find-file dired-aux
drupal/ispell drupal/eldoc drupal/autoinsert drupal-mode cc-styles
cc-align cc-engine cc-langs cc-vars cc-defs sql dired-x view cal-china
lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs
cal-french org-journal org-crypt cal-iso diary-lib diary-loaddefs
cal-move html5-schema rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid
rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn
nxml-ns nxml-mode nxml-outln nxml-rap sgml-mode facemenu nxml-util
nxml-enc xmltok reftex-dcr reftex reftex-loaddefs reftex-vars tex-mode
latexenc org-eldoc org-element avl-tree generator ol-eww eww xdg
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
pixel-fill kinsoku url-file url-dired svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus
nnheader range wid-edit ol-docview doc-view jka-compr image-mode exif
ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob-core ob-eval org-table oc-basic bibtex iso8601 ol org-keys oc
org-compat advice org-macs org-loaddefs format-spec cal-menu calendar
cal-loaddefs gitignore-mode conf-mode ffap cl-print debug backtrace
find-func vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc-got
vc-annotate vc-dir ewoc shortdoc gnutls mule-util magit-utils crm dash
log-edit message sendmail yank-media rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader add-log
whitespace pulse color display-line-numbers bug-reference edmacro kmacro
smerge-mode cl-extra wgrep executable copyright shell drupal/pcomplete
pcomplete files-x grep autoload misearch multi-isearch vc-fossil
vc-backup log-view pcvs-util vc diff vc-git diff-mode vc-dispatcher
filecache autorevert filenotify raku-detect server time-date
flymake-proc flymake project compile text-property-search comint
ansi-color warnings noutline outline easy-mmode flyspell ispell checkdoc
lisp-mnt thingatpt load-dir elec-pair reveal autoinsert savehist
minibuf-eldef disp-table compact-docstrings ede/auto eieio-base
geiser-impl help-fns radix-tree help-mode geiser-custom geiser-base ring
proof-site proof-autoloads slime-autoloads sly-autoloads rx cl-seq
engrave-faces gnu-elpa-features realgud-recursive-autoloads finder-inf
compat url-auth info package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap url-handlers url-parse auth-source eieio eieio-core cl-macs gv
pcase eieio-loaddefs password-cache json subr-x map url-vars seq
byte-opt bytecomp byte-compile cl-loaddefs cl-lib iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray button loaddefs oclosure cl-preloaded
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 1240648 196783) (symbols 48 46340 117) (strings 32 226460 23555)
 (string-bytes 1 8179239) (vectors 16 202898)
 (vector-slots 8 4464083 548777) (floats 8 1703 1486)
 (intervals 56 128360 2956) (buffers 992 267))

Message #8 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 55811 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Sun, 05 Jun 2022 22:33:19 +0200

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> I think `no-byte-compile` only means that we should load the `.el` file
> and not generate a `.elc` file and it shouldn't mean that we should
> refrain from asking the byte-compiler what is its opinion about the
> quality of this code.

I stumbled onto a related thing earlier tonight -- I said `M-x
byte-compile-file RET RET' and then it did nothing -- because of the
no-byte-compile.

I'm not sure whether I agree with that -- if I've explicitly asked Emacs
to do it, I think that should override the cookie.  Or at least issue a
message of some sort.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Sun, 05 Jun 2022 19:09:17 -0400

> I stumbled onto a related thing earlier tonight -- I said `M-x
> byte-compile-file RET RET' and then it did nothing -- because of the
> no-byte-compile.
>
> I'm not sure whether I agree with that -- if I've explicitly asked Emacs
> to do it, I think that should override the cookie.  Or at least issue a
> message of some sort.

That's a slightly different case from mine: the `no-byte-compile` is
often used either because the user really only ever wants to load the
`.el` or because the compilation is known to fail (e.g. because it
requires macros defined in a package that's not marked as a strict
dependency, very common in tests).

Generating a `.elc` file explicitly with `M-x byte-compile-file` could
be a problem if subsequent "normal" use will fail to update that `.elc`
because of the `no-byte-compile`.

So, I think `byte-compile-file` should not silently override the
`no-byte-compile`.  It could prompt to choose between "really compile"
and "compile but don't generate the .elc file".


        Stefan

Message #14 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Mon, 06 Jun 2022 14:40:29 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> So, I think `byte-compile-file` should not silently override the
> `no-byte-compile`.  It could prompt to choose between "really compile"
> and "compile but don't generate the .elc file".

Yup.  Or perhaps just issue a message that it's not doing anything --
this is a pretty obscure situation, after all.

By the way, do we have a convenient command for "compile but don't
generate the .elc file" somewhere?  (I feel like I've asked this before,
but I've suppressed the memory of the answer.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 07:41:41 +0100

Hi Stefan,

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> That's a slightly different case from mine: the `no-byte-compile` is
> often used either because the user really only ever wants to load the
> `.el` or because the compilation is known to fail (e.g. because it
> requires macros defined in a package that's not marked as a strict
> dependency, very common in tests).

By this you mean that the provider of such macros is not `require`d?
Then I don't understand what Flymake's byte-compilation backend could do
about this either...  As far as I understand it would just red-underline
all the unknown macro-using forms, their bodies wouldn't be checked.  Is
this what you want?  To check the rest of the file regardless?

Of course you know this -- but just to clarify -- the byte-compilation
backend works by launching a Emacs -Q which is asked to byte-compile
only a file containing the current buffer's contents.  During that
byte-compilation nothing more is loaded apart from what is preloaded or
explicitly loaded by the file at compile-time (via require or
eval-when/and-compile stuff).

A related issue is that when there _is_ an explicit require, then the
load-path support is pretty poor: only the current directory is added to
it.  If the `require`'d file lives somewhere else, there's no way to
hint that to the byte-comp backend, with a particular load-path.

Anyway, maybe you could give small example of such a file containing
such a cookie where you think Flymake's "I refuse to lint this" behavior
could be improved.

João

Message #20 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 07:47:24 -0400

> Of course you know this -- but just to clarify -- the byte-compilation
> backend works by launching a Emacs -Q which is asked to byte-compile
> only a file containing the current buffer's contents.  During that
> byte-compilation nothing more is loaded apart from what is preloaded or
> explicitly loaded by the file at compile-time (via require or
> eval-when/and-compile stuff).

This bug-report is about the fact that there is no benefit to
obeying `no-byte-compile` in flymake.  Not about improving the way the
sub-process reproduces a "good" initial state to compile the file
(e.g. set up of `load-path` and whatnot).

> Anyway, maybe you could give small example of such a file containing
> such a cookie where you think Flymake's "I refuse to lint this" behavior
> could be improved.

A good example are all the files in the
[EEV](http://elpa.gnu.org/packages/eev.html) package.


        Stefan

Message #23 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 13:54:52 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> This bug-report is about the fact that there is no benefit to
> obeying `no-byte-compile` in flymake.

Well, there are some.  If you open, say, lisp/net/tramp-loaddefs.el,
you'll get a whole bunch of compilation errors, and you don't want to
see those, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #26 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 13:02:41 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Of course you know this -- but just to clarify -- the byte-compilation
>> backend works by launching a Emacs -Q which is asked to byte-compile
>> only a file containing the current buffer's contents.  During that
>> byte-compilation nothing more is loaded apart from what is preloaded or
>> explicitly loaded by the file at compile-time (via require or
>> eval-when/and-compile stuff).
>
> This bug-report is about the fact that there is no benefit to
> obeying `no-byte-compile` in flymake.  Not about improving the way the
> sub-process reproduces a "good" initial state to compile the file
> (e.g. set up of `load-path` and whatnot).

Sure, I understood.  I was just commenting on the fact that the quality
of Flymake diagnostics might not be so good/helpful since those
diagnostics are likely affected by the same root causes that prevent
normal byte compilation anyway.

( Also, on the tangent note about load-path and Flymake, I completely
forgot that I added elisp-flymake-byte-compile-load-path some 4 years
ago.)

>> Anyway, maybe you could give small example of such a file containing
>> such a cookie where you think Flymake's "I refuse to lint this" behavior
>> could be improved.
>
> A good example are all the files in the
> [EEV](http://elpa.gnu.org/packages/eev.html) package.

OK.  Try this "100% untested patch" (TM) then:

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 70826b4c3a..b99007c938 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2152,7 +2152,9 @@ elisp-flymake--batch-compile-for-flymake
                   collected)
             t)))
     (unwind-protect
-        (byte-compile-file file)
+        (progn
+          (setq-local no-byte-compile nil)
+          (byte-compile-file file))
       (ignore-errors
         (kill-buffer byte-compile-log-buffer)))
     (prin1 :elisp-flymake-output-start)

Message #29 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 13:13:42 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> This bug-report is about the fact that there is no benefit to
>> obeying `no-byte-compile` in flymake.
>
> Well, there are some.  If you open, say, lisp/net/tramp-loaddefs.el,
> you'll get a whole bunch of compilation errors, and you don't want to
> see those, I think?

They could be useful I guess.  There are two cases to distinguish here
(which is what I failed to clarify before).  Perhaps Stefan is thinking
of the second.

1. The file has this form:

      (require 'foo)
       
      (fooey-macro (some-shady-stuff-the-byte-comp-could-look-into))

      (some-more-shady-stuff)

      ;; Local Variables:
      ;; no-byte-compile: t
      ;; End:

   and the reason for adding the no-byte-compile cookie is that foo.el
   can't be found at compile-time.  Then I think there is little reason
   to activate Flymake there.  That's because Flymake will halt at the
   (require 'foo) and not look into the rest of the file.

2. The file is identical but doesn't have the (require 'foo), then, I
   think Flymake will underline the first form, but carry on looking
   into other stuff.  This is possibly helpful, according to one's
   own tolerance of signal-to-noise ratio.

If some files in case 2 are still unbearably noisy for some, then I
think there are existing ways to force Flymake off using buffer-local
variables.
   
João

Message #32 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 08:34:34 -0400

Lars Ingebrigtsen [2022-06-07 13:54:52] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> This bug-report is about the fact that there is no benefit to
>> obeying `no-byte-compile` in flymake.
> Well, there are some.  If you open, say, lisp/net/tramp-loaddefs.el,
> you'll get a whole bunch of compilation errors, and you don't want to
> see those, I think?

Why not?


        Stefan

Message #35 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 14:42:29 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Well, there are some.  If you open, say, lisp/net/tramp-loaddefs.el,
>> you'll get a whole bunch of compilation errors, and you don't want to
>> see those, I think?
>
> Why not?

Because they can't be byte-compiled -- that's why they're marked as
such.  :-/

(There's a separate bug report about that somewhere.)

So we're really using no-byte-compile for two reasons: 1) To say that we
don't think it's useful to byte-compile something or 2) because we know
that it's impossible.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #38 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 09:46:35 -0400

> 1. The file has this form:
>
>       (require 'foo)
>        
>       (fooey-macro (some-shady-stuff-the-byte-comp-could-look-into))
>
>       (some-more-shady-stuff)
>
>       ;; Local Variables:
>       ;; no-byte-compile: t
>       ;; End:
>
>    and the reason for adding the no-byte-compile cookie is that foo.el
>    can't be found at compile-time.  Then I think there is little reason
>    to activate Flymake there.  That's because Flymake will halt at the
>    (require 'foo) and not look into the rest of the file.

BTW, while there is little benefit to having flymake run the
byte-compiler here, there is similarly little harm.
And the user may then decide to install `foo` to get the rest of the
file properly checked.


        Stefan

Message #41 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 07 Jun 2022 09:49:05 -0400

Lars Ingebrigtsen [2022-06-07 14:42:29] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> Well, there are some.  If you open, say, lisp/net/tramp-loaddefs.el,
>>> you'll get a whole bunch of compilation errors, and you don't want to
>>> see those, I think?
>>
>> Why not?
>
> Because they can't be byte-compiled -- that's why they're marked as
> such.  :-/

I don't see the relevance.  I'm not trying to byte-compile the file.
Instead I'm trying to get the byte-compiler to give me feedback about
the file.

Sometimes files marked with `no-byte-compile` will indeed give fairly
poor feedback, but not always, and in any case I find poor feedback
better than no feedback at all.


        Stefan

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: bug-gnu-emacs <at> gnu.org
Subject: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile files
Date: Sun, 19 Jan 2025 18:31:55 -0500

[Message part 1 (text/plain, inline)]

> As the title says, if you enable `flymake-mode` in an ELisp file with
> a `no-byte-compile: t` in its file-local variables you don't get any
> diagnostics from the compiler (you do still get diagnostics from
> checkdoc, admittedly).
>
> I think `no-byte-compile` only means that we should load the `.el` file
> and not generate a `.elc` file and it shouldn't mean that we should
> refrain from asking the byte-compiler what is its opinion about the
> quality of this code.

Greetings. It looks like this conversation didn't end up with a solution.
This is annoying enough to me that I'd like to rejuvenate the discussion.
Anyone who adds the cookie to early-init.el and init.el, for example,
misses out on flymake diagnostics.

How about adding an optional lint argument to byte-compile-file
that elisp-flymake--batch-compile-for-flymake would specify when calling
b-c-f? b-c-f, with lint specified, would ignore no-byte-compile for that
call. Looks like a three-line change. I'm sure I'm missing some subtleties?
I could submit a patch for this, if people agree.

-Stephane

[Message part 2 (text/html, inline)]

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#55811: 29.0.50;
 No flymake diagnostics for no-byte-compile files
Date: Sun, 19 Jan 2025 18:57:33 -0500

[Message part 1 (text/plain, inline)]

I think just the lint argument to byte-compile-file should suffice and no
change to no-byte-compile needed. Lint will always be run. The only reason
I can see to add no-byte-compile is for those files which, for whatever
reason, really should never be run through the byte compiler (are there
any?).

On Sun, Jan 19, 2025 at 6:31 PM Ship Mints <shipmints <at> gmail.com> wrote:

> > As the title says, if you enable `flymake-mode` in an ELisp file with
> > a `no-byte-compile: t` in its file-local variables you don't get any
> > diagnostics from the compiler (you do still get diagnostics from
> > checkdoc, admittedly).
> >
> > I think `no-byte-compile` only means that we should load the `.el` file
> > and not generate a `.elc` file and it shouldn't mean that we should
> > refrain from asking the byte-compiler what is its opinion about the
> > quality of this code.
>
> Greetings. It looks like this conversation didn't end up with a solution.
> This is annoying enough to me that I'd like to rejuvenate the discussion.
> Anyone who adds the cookie to early-init.el and init.el, for example,
> misses out on flymake diagnostics.
>
> How about adding an optional lint argument to byte-compile-file
> that elisp-flymake--batch-compile-for-flymake would specify when calling
> b-c-f? b-c-f, with lint specified, would ignore no-byte-compile for that
> call. Looks like a three-line change. I'm sure I'm missing some subtleties?
> I could submit a patch for this, if people agree.
>
> -Stephane
>

[Message part 2 (text/html, inline)]

Message #50 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 55811 <at> debbugs.gnu.org
Subject: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile files
Date: Mon, 20 Jan 2025 05:35:20 -0500

[Message part 1 (text/plain, inline)]

> As the title says, if you enable `flymake-mode` in an ELisp file with
> a `no-byte-compile: t` in its file-local variables you don't get any
> diagnostics from the compiler (you do still get diagnostics from
> checkdoc, admittedly).
>
> I think `no-byte-compile` only means that we should load the `.el` file
> and not generate a `.elc` file and it shouldn't mean that we should
> refrain from asking the byte-compiler what is its opinion about the
> quality of this code.

Greetings. It looks like this conversation didn't end up with a solution.
This is annoying enough to me that I'd like to rejuvenate the discussion.
Anyone who adds the cookie to early-init.el and init.el, for example,
misses out on flymake diagnostics.

How about an added optional "lint" or "ignore-no-byte-compile" argument to
byte-compile-file to cause b-c-f to allow the byte compiler to run despite
the buffer local var? elisp-flymake--batch-compile-for-flymake would use
the new argument when calling b-c-f. Looks like a small change. I'm sure
I'm missing some subtleties? I could submit a patch for this, if people
agree.

-Stephane

[Message part 2 (text/html, inline)]

Message #53 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 21 Jan 2025 06:00:05 -0500

>> I think `no-byte-compile` only means that we should load the `.el` file
>> and not generate a `.elc` file and it shouldn't mean that we should
>> refrain from asking the byte-compiler what is its opinion about the
>> quality of this code.
> Greetings. It looks like this conversation didn't end up with a solution.
> This is annoying enough to me that I'd like to rejuvenate the discussion.
> Anyone who adds the cookie to early-init.el and init.el, for example,
> misses out on flymake diagnostics.

Did you have a chance to try the patch sent by João?


        Stefan

Message #56 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Ship Mints <shipmints <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 21 Jan 2025 06:01:28 -0500

> OK.  Try this "100% untested patch" (TM) then:
>
> diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> index 70826b4c3a..b99007c938 100644
> --- a/lisp/progmodes/elisp-mode.el
> +++ b/lisp/progmodes/elisp-mode.el
> @@ -2152,7 +2152,9 @@ elisp-flymake--batch-compile-for-flymake
>                    collected)
>              t)))
>      (unwind-protect
> -        (byte-compile-file file)
> +        (progn
> +          (setq-local no-byte-compile nil)
> +          (byte-compile-file file))
>        (ignore-errors
>          (kill-buffer byte-compile-log-buffer)))
>      (prin1 :elisp-flymake-output-start)

I didn't test it, but if this works, it looks good to me,


        Stefan

Message #59 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 João Távora <joaotavora <at> gmail.com>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50;
 No flymake diagnostics for no-byte-compile files
Date: Tue, 21 Jan 2025 07:32:31 -0500

[Message part 1 (text/plain, inline)]

Indeed. I'd forgotten that the flymake byte compiler runs in a subprocess,
rendering locals overrides in the calling process useless. That at least
addresses flymake.

Without a flag or bound variable to inform byte-compile-file to ignore
no-byte-compile, elisp-byte-compile-buffer and elisp-byte-compile-file,
which do run in process, fail silently.

Would be great to adopt the simple flymake change in master, if not also in
30 (I can hear the hoots of "it's too late for 30" already). The patch is
not really practical when using a packaged Emacs. In the meantime, I'll
disable no-byte-compile.

On Tue, Jan 21, 2025 at 6:01 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> > OK.  Try this "100% untested patch" (TM) then:
> >
> > diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> > index 70826b4c3a..b99007c938 100644
> > --- a/lisp/progmodes/elisp-mode.el
> > +++ b/lisp/progmodes/elisp-mode.el
> > @@ -2152,7 +2152,9 @@ elisp-flymake--batch-compile-for-flymake
> >                    collected)
> >              t)))
> >      (unwind-protect
> > -        (byte-compile-file file)
> > +        (progn
> > +          (setq-local no-byte-compile nil)
> > +          (byte-compile-file file))
> >        (ignore-errors
> >          (kill-buffer byte-compile-log-buffer)))
> >      (prin1 :elisp-flymake-output-start)
>
> I didn't test it, but if this works, it looks good to me,
>
>
>         Stefan
>
>

[Message part 2 (text/html, inline)]

Message #62 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 João Távora <joaotavora <at> gmail.com>,
 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile
 files
Date: Tue, 21 Jan 2025 17:07:09 -0500

> Would be great to adopt the simple flymake change in master,

Do I understand correctly that you tried it and it worked for you?


        Stefan

Message #65 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 João Távora <joaotavora <at> gmail.com>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50;
 No flymake diagnostics for no-byte-compile files
Date: Tue, 21 Jan 2025 20:16:49 -0500

[Message part 1 (text/plain, inline)]

Sorry I wasn't clear. Joao's suggestion will not work.

elisp-flymake--batch-compile-for-flymake invokes byte-compile-file in a
subprocess which loads the input file into a fresh buffer with reset buffer
locals, negating the parent-process call-site patch's intention.

Disabling no-byte-compile has to happen in
elisp-flymake--batch-compile-for-flymake to influence byte-compile-file.
I've used a new defvar to let bind in the spirit
of bytecomp--inhibit-lexical-cookie-warning.

I've attached a patch that works for me, along with an appropriate commit
log message.

-Stephane

On Tue, Jan 21, 2025 at 5:07 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> > Would be great to adopt the simple flymake change in master,
>
> Do I understand correctly that you tried it and it worked for you?
>
>
>         Stefan
>
>

[Message part 2 (text/html, inline)]

[0001-elisp-flymake-batch-compile-for-flymake-ignore-no-by.patch (application/octet-stream, attachment)]

Message #68 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 João Távora <joaotavora <at> gmail.com>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50;
 No flymake diagnostics for no-byte-compile files
Date: Wed, 22 Jan 2025 10:06:46 -0500

[Message part 1 (text/plain, inline)]

If you test this on a recent build, you need to deal with trusted content.
I ran this before loading a "trusted" test file (setq trusted-content :all).

On Tue, Jan 21, 2025 at 8:16 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Sorry I wasn't clear. Joao's suggestion will not work.
>
> elisp-flymake--batch-compile-for-flymake invokes byte-compile-file in a
> subprocess which loads the input file into a fresh buffer with reset buffer
> locals, negating the parent-process call-site patch's intention.
>
> Disabling no-byte-compile has to happen in
> elisp-flymake--batch-compile-for-flymake to influence byte-compile-file.
> I've used a new defvar to let bind in the spirit
> of bytecomp--inhibit-lexical-cookie-warning.
>
> I've attached a patch that works for me, along with an appropriate commit
> log message.
>
> -Stephane
>
> On Tue, Jan 21, 2025 at 5:07 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>
>> > Would be great to adopt the simple flymake change in master,
>>
>> Do I understand correctly that you tried it and it worked for you?
>>
>>
>>         Stefan
>>
>>

[Message part 2 (text/html, inline)]

Message #71 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 João Távora <joaotavora <at> gmail.com>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50;
 No flymake diagnostics for no-byte-compile files
Date: Thu, 23 Jan 2025 13:10:55 -0500

[Message part 1 (text/plain, inline)]

Anyone want to give this a try (especially someone with commit rights)?
It's a simple enough change to make it into Emacs 30.1 or .2, too.

On Tue, Jan 21, 2025 at 8:16 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Sorry I wasn't clear. Joao's suggestion will not work.
>
> elisp-flymake--batch-compile-for-flymake invokes byte-compile-file in a
> subprocess which loads the input file into a fresh buffer with reset buffer
> locals, negating the parent-process call-site patch's intention.
>
> Disabling no-byte-compile has to happen in
> elisp-flymake--batch-compile-for-flymake to influence byte-compile-file.
> I've used a new defvar to let bind in the spirit
> of bytecomp--inhibit-lexical-cookie-warning.
>
> I've attached a patch that works for me, along with an appropriate commit
> log message.
>
> -Stephane
>
> On Tue, Jan 21, 2025 at 5:07 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>
>> > Would be great to adopt the simple flymake change in master,
>>
>> Do I understand correctly that you tried it and it worked for you?
>>
>>
>>         Stefan
>>
>>

[Message part 2 (text/html, inline)]

Message #74 received at 55811 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 João Távora <joaotavora <at> gmail.com>, 55811 <at> debbugs.gnu.org
Subject: Re: bug#55811: 29.0.50;
 No flymake diagnostics for no-byte-compile files
Date: Mon, 3 Feb 2025 15:57:17 -0500

[Message part 1 (text/plain, inline)]

Is it possible to get some traction on this patch?

TIA,

-Stephane

On Tue, Jan 21, 2025 at 8:16 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Sorry I wasn't clear. Joao's suggestion will not work.
>
> elisp-flymake--batch-compile-for-flymake invokes byte-compile-file in a
> subprocess which loads the input file into a fresh buffer with reset buffer
> locals, negating the parent-process call-site patch's intention.
>
> Disabling no-byte-compile has to happen in
> elisp-flymake--batch-compile-for-flymake to influence byte-compile-file.
> I've used a new defvar to let bind in the spirit
> of bytecomp--inhibit-lexical-cookie-warning.
>
> I've attached a patch that works for me, along with an appropriate commit
> log message.
>
> -Stephane
>
> On Tue, Jan 21, 2025 at 5:07 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>
>> > Would be great to adopt the simple flymake change in master,
>>
>> Do I understand correctly that you tried it and it worked for you?
>>
>>
>>         Stefan
>>
>>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.