Emacs 24.3 or below
There's no built-in way of preventing these old files from being loaded, but
there are easy ways to get rid of them.
You can recompile the entire elpa directory by calling:
M-x byte-recompile-directory RET ~/.emacs.d/elpa/.
This should get rid of outdated files.
You can use the
auto-compile package and
activate auto-compile-on-load-mode ...
For the benefit of clueless readers arriving here, allow me a small digression to say that these warnings generally point to real code issues (and when they don't, you can suppress them on a per-variable basis) so people should research what they mean before disabling them.
Of course, I have no doubt that you know why you need to disable it, so the answer ...
The defcustom expression are not evaluated during byte-compilation, so when your macro is expanded, the variable does not exist yet because that defcustom was compiled but not run. You can either move the defcustom to another file (which you then require at the beginning of your file), or you can wrap the defcustom inside eval-and-compile.
If you only set load-prefer-newer (where available), the correct code will get loaded, but it might not have been byte-compiled, so there may be a slight performance penalty.
You can use Jonas Bernoulli's excellent auto-compile library to help make sure this problem doesn't arise. In particular, auto-compile-on-load-mode will recompile outdated .elc files ...
All macros reachable by the byte-compiler are expanded during compilation.
"Reachable" essentially means not being quoted.
The body of defuns, defmacros, lambdas, are all byte-compiled
when the source file that contains them is byte-compiled. So yes, any
macro inside them will be expanded, as long as they're not inside a
quote ('). A very common mistake is ...
I have both .el and the byte compiled version (.elc) of an elisp file. Accidentally I delete the .el file. Can I retrieve the .el file from its .elc version?
In practice, no.
In theory you could use the elc file to produce an el file with human readable definitions. However, this probably wouldn't look the same as the original file you deleted, due to ...
New users of Lisp who come from other languages sometimes use strings for such purposes out of habit.
Symbols can be compared with eq instead of just equal. string= uses code similar to equal, to test each character until a mismatch is found. So yes, symbol comparison can be slightly faster. If you are using the comparison in a loop, for instance, the ...
Yes you can using byte-defop-compiler to actually specify a function that compiles your function, byte-defop-compiler has some built in niceties to help you specify that your functions should yield warnings based on having a number of args.
Add a compiler-form for FUNCTION.If function is a symbol, then the variable "byte-SYMBOL" must name the ...
You don't use i and that's what the byte-compiler tells you.
To let the byte-compiler know that you're aware of the fact that the variable is unused, give it a name that starts with an underscore. E.g.
(dotimes (_ 10) ...)
(dotimes (_i 10) ...)
My problem was that the byte-compiled version of csharp-mode wasn't compatible with the upgrade. It seems it's a good idea to recompile all files on upgrading emacs, see this question: https://stackoverflow.com/questions/24725778/how-to-rebuild-elpa-packages-after-upgrade-of-emacs
tl;dr: M-: (byte-recompile-directory package-user-dir nil 'force) fixes all ...
The byte-compiler's way to decide whether a function will be defined or not is very "naive" and gets fooled even in your "obvious" case.
But you can write it in a way that lets the compiler understand what happens:
(let ((count 0))
(setq count (1+ count))
(message "Count is: %d" ...
The compilation you refer to is usually called byte-compilation of emacs lisp. It generates a different and faster representation of functions for the emacs interpreter. Unlike compilation of C code using gcc where the resulting code is run directly by the hardware, byte-compiled code still needs the Emacs interpreter.
Emacs comes with a native compiler ...
require is not meant to avoid recusive loading, it is meant to avoid repetitive loading. So no, it does not solve you problem here.
About the problem
The right way to approach this (in my opinion) would be to avoid the
The test1 file in your example has no reason to require test2.
Even if that's not true for your actual ...
There isn't a lot of logic behind this. At least, not in the sense of a conscious decision. It's more of a feature of the compilation process that really doesn't apply to package management but nobody has bothered to fix it yet.
Whenever Emacs is about to compile something it asks you if you want to save edited buffers. That's actually something very ...
Note that the lisp reader interns symbols, such that independent references to a given symbol give you the exact same lisp object, and consequently you're able to compare them with eq (which only needs to compare the object addresses).
Conversely, independent strings are always different lisp objects, and therefore you have to compare their contents.
How do you recompile an .el source file [...]
In Elisp file-visiting buffers, you can run the command M-xemacs-lisp-byte-compileRET to byte-compile the corresponding file.
In Dired buffers, you can type B (dired-do-byte-compile) to byte-compile all specified Elisp files.
In all buffers, you can run the command M-xbyte-compile-fileRET to byte-compile an ...
Try using a ~/.emacs.d/elpa/.dir-locals.el file containing:
((emacs-lisp-mode . ((no-byte-compile . t))))
no-byte-compile is generally intended to be used as a file-local variable (see C-hig (elisp) Byte Compilation RET), but a quick experiment suggests that it works just fine as a dir-local, and successfully inhibits byte compilation when installing ELPA ...
The Emacs manual node on byte compilation explains that elisp
... has a compiler that translates functions written in Lisp into a special representation called byte-code that can be executed more efficiently. The compiler replaces Lisp function definitions with byte-code.
These byte-codes are basically numeric codes that are not human readable (byte-car, ...
If you look in byte-optimize-form-code-walker, you can see that a warning is printed for side-effect-free functions, but error-free functions just get optimized out and logged (not warned) only. Logging means it only shows up if have byte-optimize-log set to non-nil (you'll want to set it to source otherwise there's a lot of noise).
((and for-effect (...
To suppress the byte-compiler warning, try adding this before your code, starting in column 0 (leftmost):
(declare-function increase-count "your-file-name.el")
C-h f declare-function tells you:
declare-function is a Lisp macro in subr.el.
(declare-function FN FILE &optional ARGLIST FILEONLY)
Tell the byte-compiler that function FN is ...
I'd say stick with defun.
If you want to try define-inline, which is new (it doesn't even have a doc string yet!), go ahead.
But think about how much you want or need inlining. It is rare to need it, IMO (certainly not for the kinds of thing you show here, but they are no doubt just to get the question across).
I would definitely recommend not to use ...
Before the advent of eager (load-time) macro expansion, I would have said this was crazy talk, and told you to forget the idea and compile everything as usual.
Maybe it's somewhat less crazy now that macros are generally not expanded upon each evaluation -- but compiled elisp is still going to be faster (by varying margins) for pretty much everything, and ...
If you look at (symbol-plist 'not) you will see that it has a byte-opcode property with value byte-not. So the elisp compiler will use this rather than a general function call.
I have not looked for documentation.
If you look at the lisp/emacs-lisp/bytecomp.el file in the source you will find a whole series of byte-XXXX values which are used in this way, ...
By default the .elc would be loaded rather than the .el, as noted in the other answers/comments.
A few things can affect this behavior, however:
Set load-prefer-newer to t if you want to load whichever file is newer. In that case the .el will be loaded if it has been modified more recently than the corresponding .elc file.
See the variable load-suffixes, ...
See the answer by Drew for a general description of compiler warnings pertaining to free variables.
In your particular case, however, the culprit is the package oauth2.el, which for some reason is getting loaded during the byte-compilation of your user-init-file (perhaps you are a use-package user?).
In this case adding (defvar foo) to your user-init-file ...
Your question is a little confusing, but I suspect you actually mean that you've byte-compiled the prelude-ivy.el library (as opposed to "reading the source file"), and that the compiler has produced a warning that the function prelude-require-packages is not known to be defined (n.b. not "prelude-required-packages", which does not appear anywhere in the ...