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) ...)
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.
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 (...
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 ...
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.
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 ...
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.
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 ...
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
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 ...
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:
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 ...
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)
-> is a Lisp macro in `dash.el'.
Macros don't follow the usual rules for function definition which is likely why you're getting this error.
You might be able to do it by explicitly requiring dash in your file, if you haven't already. There's another thread regarding a similar issue around elisp macros that might be relevant Make flycheck's "...
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 ...
Something in your init file is invoking font-lock-fontify-buffer. You can track it down and see if you want to change it as suggested by the warning. Or you can ignore it.
Emacs has added a ton of byte-compilation warnings in recent years. Most can be ignored, in the sense that there will be no negative effects. Most of the time they serve mainly as ...
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.
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 ...
Function spacemacs/delete-current-buffer-file is defined in spacemacs-base/funcs.el.
You can override it with the desired function. Note that I just changed the prompt of the yes-or-no-p question.
(defun my-spacemacs/delete-current-buffer-file ()
"Removes file connected to current buffer and kills buffer."
(let ((filename (buffer-file-...
The problem is very simple: You added ~/.emacs.d/ to your load-path.
Remove it from your load-path and things will go back to normal. This directory should not be in your load-path because it does not contain source code packages, but data files. And some of them can (and do) have names that match those of packages, so if you add it like you did, when ...
According to commends on Emacs bug#16522: (https://lists.gnu.org/archive/html/bug-gnu-emacs/2014-01/msg01157.html), this is a bug when using Emacs with GTK version earlier than 2.16.
I've personally seen this on RHEL 5 (GTK 2.10.4), but not on RHEL 6 (GTK 2.24.23).