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 ...
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 ...
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.
EDIT: A better way to do this in recent Emacs is by defining a compiler macro to check the number of arguments. My original answer using a normal macro is preserved below, but a compiler-macro is superior because it does not prevent passing the function to funcall or apply at runtime.
In recent versions of Emacs, you can do this by defining a compiler-...
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) ...)
No, set and setq do not declare lexical variables. Only let does. Had you used let here you'd have a bug, but this is fine. The warning exists mostly to catch typos when using dynamic variables.
To make the warning go away use defvar as in your question, but do not quote the symbol.
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 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 ...
As Malabarba has already explained, macros are expanded during byte compilation. If a file is not compiled, macros are expanded when the file is loaded (eager macro expansion).
Don't rely on this, though. It's very bad style. You generally can't expect that code which uses your macro is actually compiled, and you should generally run as little code as ...
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.
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" ...
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 (...
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 ...
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 ...
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, ...
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 ...
I agree with @wvxvw's comment: You don't need to move the *.elc files; it is enough to not look at them. ;-) You can hide them from a Dired listing, for example.
But if you really want to have byte-compiling automatically put the *.elc result in a different directory then you can set variable byte-compile-dest-file-function to a function that is similar to ...
This happens due to display-warning delaying warnings until after init time. By then, the file name and location are no longer known.
(defun display-warning (type message &optional level buffer-name)
(if (not (or after-init-time noninteractive (daemonp)))
;; Ensure warnings that happen early in the startup sequence
;; are visible ...
To add to what @Malabarba said, I think the problem here is that smartparens should provide an API that does not rely on a macro.
The "normal" way this works with usual packages is that the major mode can just do something like:
(when (boundp 'smartparens-thingies)
(push mythingies smartparens-thingies))
(setq smartparens-extra-thingies ...