I have to copy my .emacs.d
to different computers a lot, so I keep init.el
etc in version control and pair it with a batch Elisp script that re-downloads all of my selected packages. I'd like this script to be less noisy, and in particular I'd like it to not bother me with compilation diagnostics for packages that I have no interest in hacking on.
I tried to squelch all the warnings like so:
(package-refresh-contents)
(let ((package-native-compile t)
(byte-compile-warnings nil)
(native-comp-async-report-warnings-errors nil))
(package-install-selected-packages t)
;; Block until native compilation has finished.
(while (or comp-files-queue
(> (comp-async-runnings) 0))
(sleep-for 1)))
...but this (specifically, the let-binding of byte-compile-warnings
and native-comp-async-report-warnings-errors
) appears to have no effect (it's possible that it is suppressing some warnings, but not the particular ones that flood my terminal). What should I be doing instead of, or in addition to, this?
Note: the bootstrap script is not itself byte-compiled, and does not use lexical binding mode.
Note: examples of the warnings I'm still seeing with this code:
json-snatcher.el:222:25: Warning: value returned from (match-end 0) is unused
polymode-core:0: Warning: Not registering prefix "pm". Affects: (...)
Warning (comp): mime-w3.el:52:45: Warning: reference to free variable ‘w3-mode-map’
Warning (comp): mime-w3.el:62:21: Warning: Use ‘with-current-buffer’ rather than save-excursion+set-buffer
Warning (comp): mime-w3.el:50:12: Warning: the function ‘w3-region’ is not known to be defined.Warning (comp): web-mode.el:11455:36: Warning: Unused lexical variable `end'
P.S. If anyone knows how to cut down the spew generated by package-install
itself, that'd also be great. Ideally I would like to see just "Package ‘foo’ installed" for each package, and not the rest of this:
Contacting host: melpa.org:443
Parsing tar file...
Parsing tar file...done
Extracting... \
Extracting...done
INFO Scraping files for cython-mode-autoloads.el...
INFO Scraping files for cython-mode-autoloads.el...done
Checking .../elpa/cython-mode-20221130.1257...
Compiling .../elpa/cython-mode-20221130.1257/cython-mode-autoloads.el...
Compiling .../elpa/cython-mode-20221130.1257/cython-mode-pkg.el...
Compiling .../elpa/cython-mode-20221130.1257/cython-mode.el...
Done (Total of 1 file compiled, 2 skipped)
Package ‘cython-mode’ installed.
json-snatcher
withbyte-compile-warnings
set tot
andnil
and it certainly makes a difference: there is an extra 16 lines of output (warnings and empty lines) witht
as compared with the output when the variable is set tonil
. In particular, I don't see the warning in the first line of your example output. I don't have native compilation set up, so I can't test that part..elc
and.eln
files, are you??? Committing build output has to be item #1 on the hypothetical Big List Of Things Not To Do With Version Control. Also, it won't work, since not all of the computers in question have the same CPU architecture or even the same major version of Emacs..elc
files are very portable, so you can commit those if they will be executed on the-same-or-newer version of Emacs, regardless of system architecture. It's a pretty good idea to match your Emacs versions between systems for consistency, in which case you can very safely have your byte-compiled lisp committed. An emacs config isn't (typically) software that lots of people will be using and compiling -- usually it's just for you, and committing the compiled files can make things better for you. I think the "clone and go" benefit is a strong one..eln
files though (I don't use them, so it slipped my mind). IIRC the filename hashes for those take architecture into account, in which case I suspect you could safely commit them; however by my recollection the .eln binaries are enormous by comparison with .el and .elc files, so I wouldn't personally commit them on that basis. So compilation noise from regenerating those might be inevitable. Mind you, if I did use native-compilation, I might still sync theeln-cache
directory some other way.