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 way I've done that so far is to add a call of the shape
This function call will be optimized away, but before that the compiler will still count it as a use, so the "unused" warning won't be triggered.
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) ...)
Here's the reason why you get those warnings when you don't byte-compile the file:
My crystal ball tells me this Elisp code is within a file marked as -*- lexical-binding:t -*- (which is a good thing). When the Elisp interpreter evaluates a lambda in this mode, it creates a closure without looking at the body of the lambda so the closure conservatively ...
This is very similar to the question Is there a way to disable the “buffer is read-only” warning?, so a very similar answer seems appropriate.
You can disable these messages by setting command-error-function to a function that ignores signals buffer-read-only, beginning-of-buffer, and end-of-buffer.
(defun my-command-error-function (data context caller)
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 (...
Visit your ~/.emacs.d/init.el file and do M-x check-parens RET. It should show you the unclosed open paren in that file.
As for --debug-init, I guess you could M-x report-emacs-bug indicating that it did not help debug the problem. I think that is because of debug-ignored-errors which should probably be bound to nil during initialization.
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 ...
To suppress the warning first make sure the warnings library is loaded by entering M-x load-library RET warnings RET.
Then add the listed option to warning-suppress-types. Load the customization interface by entering M-x customize-option RET warning-suppress-types RET. Add a new top-level list-item by pressing the top-most INS button, then add two nested ...
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 ...
Something that is deprecated is not unsupported. So it's not true that you cannot use it.
A warning is not, at least in Emacs, an error. It's just a message to let you know something you might not otherwise be aware of. And many, many Emacs warnings are benign in actual use, for various reasons. You need to understand a warning, and do so in the context ...
IMHO, the right way is to ignore it. ;-)
But the standard Emacs answer is to use declare-function - see (elisp) Declaring Functions.
All you need to do is add a declare-function statement before the
first use of the function in question:
(declare-function gud-find-c-expr "gud.el" nil)
This says that gud-find-c-expr is defined in gud.el (the .el
Assuming you are using lexical binding, if the variable is dynamic, then it must be defvar'd (to ensure that lexical binding cannot treat it otherwise). AFAIK it would be a bug to not use defvar.
For a variable foo defined by some other library, you need only use:
to mark it as special/dynamic.
This is happening during package activation, so it's not your init file's fault.
The warning is telling you everything you need to know. elpy needs to load highlight-indentation, but the package's not installed.
What to do
install the missing package
or delete elpy.
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 ...
If you're going for a single file init, you can add this declare:
If you have multiple files, like I do, just require tex-site at top level, see ora-latex.el. What I do is load this always:
(add-hook 'LaTeX-mode-hook 'my-latex-hook)
But then my-latex-hook is an autoloaded function in ora-latex.el. So the whole file isn't loaded ...
Might be that the package "s" was removed from emacs default packages or that you had it somehow installed on the previous version.
The package is available on the melpa repository.
Try this in your init.el (.emacs)
'("melpa" . "http://melpa.org/packages/") t)
Then use M-x ...
It's mainly just a warning - really a suggestion.
It's pointing out that if you don't care to produce a new list from the original one, where the returned list's elements are the results of applying the function argument to the original list's elements, then you might as well just use dolist or mapc instead of mapcar.
In this case, your mapcar is, yes, ...
What you are doing is safe, because when your hook is executed LaTeX is
already loaded and LaTeX-mode-map is defined. Byte compiler cannot know
that because when it compiles your file LaTeX mode is not loaded and thus
symbol LaTeX-mode-map considered free variable.
Apart from the technique you use, you can use eval-after-load:
Much simpler than I realized: just set
mu4e-index-update-error-warning to nil.
Whether to display warnings during the retrieval process.
This depends on the ‘mu4e-get-mail-command’ exit code.
Here's a little function to toggle the setting:
(defun mu4e-toggle-ignore-warnings ()
"Toggle whether or not mu4e reports update process warnings ...
Same problem for me after updating org-ref. It is linked to the fix related to the issue mentioned by @Philopolis: https://github.com/jkitchin/org-ref/commit/a7d24f48fe6416162cb1f32d9b87934b9e6c563d
If you want to avoid this warning message at startup, a (temporary) solution is to set
(setq warning-minimum-level :emergency)
Node Warning Tips of the Elisp manual tells us:
• To avoid a compiler warning about an undefined function
that you know will be defined, use a declare-function statement
(see Declaring Functions).
• If you use many functions, macros, and variables from a certain
file, you can add a require (see require: Named Features) for
that package to avoid compilation ...
as a workaround I make it invisible by
(set-face-attribute 'flycheck-fringe-warning nil :foreground (face-attribute 'fringe :background ))
similarly, I removed the underline with
(set-face-attribute 'flycheck-warning nil :underline nil)
I'm going to guess the warnings are coming from on-the-fly compilation of ELPA packages. Try running the following code:
"Recompile all packages"
(byte-recompile-directory "~/.emacs.d/elpa" 0 t))
After M-x my-package-recompile switch the the Compile-Log buffer and see if these warnings are replicated in ...
You want to look at the functions that use line-move-visual / line-move-1 / line-move -- within the library simple.el. The error message occurs because the optional argument of noerror is not being used to suppress the error message.
However, some functions depend upon that signal error to halt an ongoing function -- e.g., the third-party optional library ...
Those are only warnings, which means that the rest of your code that loads libraries or whatever should still do that.
In that case, you can use C-h v to find out where each such variable is defined. If such a variable is defined in a library that you load, then you need tell the byte compiler not to worry about that variable, i.e., that it will be properly ...