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 ...
When using JS2 ...
Disable the checker emacs-lisp-checkdoc with the org-src-mode-hook.
(defun disable-fylcheck-in-org-src-block ()
(setq-local flycheck-disabled-checkers '(emacs-lisp-checkdoc)))
(add-hook 'org-src-mode-hook 'disable-fylcheck-in-org-src-block)
Detailed walkthrough how to find this information
First search for possible variables which change the ...
eval-after-load takes a single form, hence:
(flycheck-add-mode 'html-tidy 'web-mode)
(flycheck-add-mode 'css-csslint 'web-mode)))
If you're using Emacs 24.4 or newer, with-eval-after-load is preferable, which neatly avoids this particular source of confusion:
Flycheck does simply not use your load-path for checking. By default, it always checks files in a clean environment, using only the built-in load-path of Emacs. IOW, Flycheck always checks in emacs -Q.
To make your custom code visible to Flycheck, you can either explicitly add all directories to flycheck-emacs-lisp-load-path as well, or set flycheck-emacs-...
The good way
Simply do not use Sh Mode for buffers which do not contain shell scripts. Write your own mode instead. This is the canonical way to handle such situations in Emacs.
Write a custom major mode is easy. You can simply inherit from Sh Mode to get all of its features and commands, while still having an independent mode. Just add the following ...
As per comments, this is because you're using a globalized minor mode: https://stackoverflow.com/questions/6837511/automatically-disable-a-global-minor-mode-for-a-specific-major-mode
C-hf global-flycheck-mode led me to
C-hf flycheck-may-enable-mode and
C-hv flycheck-global-modes which tells me:
flycheck-global-modes is a variable defined in `flycheck.el'.
From Reporting results in the Flycheck manual:
To avoid flooding a buffer with excessive reports, Flycheck discards any reports and disables the corresponding syntax checker subsequently, if the total number of reported errors of any level exceeds the value of flycheck-checker-error-threshold.
And then, from the docstring of this variable:
Set flycheck-disabled-checkers to (emacs-lisp-checkdoc) via file or directory variables, i.e. M-x add-file-local-variable RET flycheck-disabled-checkers RET (emacs-lisp-checkdoc) or add-dir-local-variable RET emacs-lisp-mode RET flycheck-disabled-checkers RET (emacs-lisp-checkdoc) respectively.
See Syntax checkers in the Flycheck manual for more information....
This issue is the result of a faulty interaction between overlays with before-string/after-string properties whose contents have a display property attached. It was been reported to Emacs as bug #19201, and since been fixed in Emacs. The fix will make it into the next release.
Meanwhile, you can work around this issue by disabling Flycheck's fringe ...
Thanks J David for forcing me to look more deeply.
flycheck.el defines sh-bash, the checker used for bash; and that has a next-checker known as sh-shellcheck. Ans, as Jordon is points out, that invokes shellcheck
Poking around in 2 reveals how to supress warning in a selective manner:
# shellcheck disable=SC2029
ssh foo "$@"
Well you wouldn't want to remove the hook, as that's a global effect.
You can disable the mode on a per-buffer basis, though. Use the eval pseudo-variable. e.g. a .dir-locals.el like this would act for any/all major modes:
((nil . ((eval . (flycheck-mode 0)))))
Local variables are processed after mode hooks, so this should reliably counteract your ...
You can easily disable checkers using
(setq flycheck-disabled-checkers '(sh-shellscript sh-bash sh-zsh))
The Flycheck documentation adds more information here.
You can also disable checkers in a lambda for auto-mode-alist to have it only disable on .cfg files.
'("\\.cfg\\'" . (lambda ()
Use projectile-project-root to get the root path and add it to the list with a c++-mode-hook
(defun setup-flycheck-clang-project-path ()
(let ((root (ignore-errors (projectile-project-root))))
(add-hook 'c++-mode-hook 'setup-flycheck-clang-...
Undo all that you have done in your question. Specifically unset the executable variable of handlebars again—how did you get the idea that this could possibly work?
Then add the following to your init file instead:
'(flycheck-add-mode 'html-tidy 'web-mode))
That let's you use HTML Tidy for Web Mode. Be warned though that ...
I tried to restrict the linting to one checker with (org-lint '(link-to-local-file)), however the parsing is still going to induce a noticable delay. Maybe limiting the linter to the current subtree or using the async library can improve the performance. Anyways, below is a rather simple flycheck setup for org-lint:
As of 40469d5, Flycheck includes the warning code of ShellCheck in the messages, and provides a new option flycheck-shellcheck-excluded-warnings to exclude warnings from ShellCheck reports.
To suppress a ShellCheck warning for Flycheck, use the error list at C-c ! l to find out the corresponding error code (in square brackets at the end of the message), and ...
I don't think there's a prebuilt way to do this. I hacked around it like so. This depends on having all of your virtualenvs in ~/.virtualenvs, and having projectile installed.
(defvar my:virtualenv-directory "~/.virtualenvs/"
"The directory of virtualenvs.")
(defun my:configure-python-venv ()
"Set `python-shell-virtualenv-path' to the virtualenv ...
Enable lexical-binding for your library, with M-x add-file-local-variable-prop-line RET lexical-binding RET t.
Please do not use lexical-let as suggested by the other answer. Flycheck itself is not compatible with Emacs 23, so there is no point in trying to maintain Emacs 23 compatibility in your own code.
You can achieve this locally by using cl.el's lexical-let:
(eval-when-compile '(require 'cl))
(defun my-test-caller (func)
(lexical-let ((ext-func func))
(lambda (status) (funcall ext-func)))))
(my-test-caller #'(lambda() (message "called")))
To be explicit as the help says:
Like `let', but ...
The help-echo property can be a function that returns the actual string to display, so you could add an additional overlay with higher priority with a special help-echo property which will compute the union/concatenation of all the help-echo properties it covers.
You can change the color but you cannot change the thickness.
There are two ways:
M-xlist-faces-displayRET, find flycheck-error click it, edit the underline color -> Apply and Save
You can add some piece of code to your init file:
(set-face-attribute 'flycheck-error nil :underline '(:color "red2" :style wave)) where red2 is the color used.
The only way you would get that error is if you were using the shellcheck checker, in order to remove these warnings you need to customize the command flycheck is using for shellcheck, there is no built in way to customize the existing shellcheck checker, but you can create a new checker with that feature.
You'll need to create a new flycheck checker that ...
By default Flycheck hooks into the standard error navigation of Emacs to make error navigation for Flycheck as simple as possible.
You can disable this feature by setting flycheck-standard-error-navigation to nil. Emacs' standard bindings will now ignore Flycheck's errors. You can still navigate these with Flycheck's own navigation bindings C-c ! n and ...
Flycheck does not provide a generic way to ignore warnings, partly because no one implemented that feature yet, but mostly because we do not want to add yet another system to manage warnings to inline comments, configuration files, compiler flags, etc… Warning control is already complicated enough without adding our ingredients to the soup.
Here's the format that the checker is actually expecting:
;;; init.el --- Initialization file for Emacs
;;; Commentary: Emacs Startup File --- initialization for Emacs
If you place this at the top of your init.el it'll remove the warning.
You can get emacs to insert this for you automatically by going to the menu and selecting Emacs-Lisp->Check ...