Suppose I have a VIM plugin that is very useful, but it generates a lot of errors/warnings that I don't care for.
How can I ignore all errors from that plugin? I just want to be disturbed by these messages anymore.
Is there any setting/function call that turns off such things?
I know that the best thing would be to report this as issue, but how can I just make them not appear?
Example of errors:
Well, I would definitely look into the root cause of the errors, as it might affect the plugin's functionality. At least this should allow you to send a precise bug report to the plugin's author.
Errors and warnings can be suppressed via the :silent! (note the !) command. Basically, any Ex command can be prefixed with it. So, if you have a :TroublesomeCommand, you can silence the errors via
:silent! TroublesomeCommand
To silence the plugin (if you really must), you can might be able to redefine its mappings (to include :silent!) and commands, but the use of <SID> may force you to modify the plugin itself. In that case, you can also put the :silent! directly before the offending command (the error should include its location), but again, fixing the root cause would be preferable.
Related
I have used ESLint with Vim and various other plugins like Ale and Prettier. I am now having a lot of difficulty setting things up again. It would be useful for me to know what the ESLint plugin does without any other plugins at all or any other configuration of Vim or neovim.
I am finding the documentation very difficult to follow. I think this is partly because ESLint works in many contexts not just Vim` and also much of what is written assumes other plugins are installed e.g. Ale.
I am guessing that if you are editing a Vim file (perhaps only if it has .js extension?) you can then go into normal mode and invoke ESLint (e.g. :eslint) and then see any errors in the code indicated.
The basics
For the sake of simplification, ESLint is best thought of as a standalone command-line linter, that is not related in any way to Vim or any other text editor/IDE.
The default usage pattern is to execute it in your shell with files as arguments:
$ eslint goodfile.js
(no output)
$ eslint badfile.js
(list of errors)
It can also be used as filter:
$ echo 'console.log(1)' | eslint --stdin
(list of errors)
It can also be told to fix what it can instead of merely reporting it:
$ eslint --fix badfile.js
In Vim
Like lots of command-line programs (linters or not), ESLint can be used from Vim in lots of ways.
The simplest is to execute it directly on the current file:
:!eslint %
(list of errors)
or on the current buffer if it is not written to disk:
:w !eslint --stdin
(list of errors)
But that method, while informative, is not very useful because the errors disappear as soon as you press <CR>.
A much better approach is to use the :make command, which populates the quickfix list with the errors reported by the underlying linter or compiler or whatever. In general, it works like this:
Tell Vim to use program foo for :make with set makeprg=foo.
Tell Vim how to parse the output of foo with set errorformat+=<pattern>.
Do :make % to run the current file through foo.
Do :cwindow to show the list of errors reported by foo, if any.
In the case of ESLint, if your Vim is recent enough, it should come with what it calls a "compiler script" (that I wrote), which basically does steps #1 and #2 above for you. You can check if you have it with:
:compiler eslint
If you get an error, consider this as an opportunity to upgrade.
After you have selected a compiler, you can perform steps #3 and #4 above to lint your file, which is, let's be honest, tedious.
From there, you can choose one of three paths:
keep doing it like that because it's fine,
learn a little more of your editor in order to automatise the whole process,
give up on the tinkering and use a third-party plugin.
Path #2 looks like this. It is not particularly hard or complicated but I wouldn't recommend to a copy/pasting newbie.
Path #3 involves installing a plugin like ALE, which is throughly documented and has a dedicated issue tracker.
I have some specific settings for my latex highlighting and am using the indentLine plugin, which requires let g:indentLine_fileTypeExclude = ['tex', 'bib'] to avoid the conceal feature annoyance. Anyway, when I start vim with vim filename.tex my vimrc gets loaded properly, but when I simply call vim and then open a given tex file, it'll ignore the vimrc.
Any idea what's causing it? Also, let me know what information you need, as I am far from certain on what would be needed.
EDIT:
Okay so I've found that for both cases i'm in a [tex] environment, but if I'm in a [plaintex] environment then the weirdness doesn't happen. If that helps anyone.
2nd EDIT:
New development, it is only the first file that's opened that seems to ignore the exclusion for indentLine, the remainder are shown exactly as they ought to.
The plaintex is a separate filetype in Vim (cp. :help ft-plaintex), so you need to add it to the IndentLine config:
let g:indentLine_fileTypeExclude = ['tex', 'plaintex', 'bib']
Edit This now looks like a command ordering issue. It's hard to remotely troubleshoot this, as the exact plugins and their initialization order may be important. Please capture a full log of a Vim session with vim -V20vimlog. After quitting Vim, examine the vimlog log file for the ordering of commands (but it might be difficult to see what's happening in a potentially vast list of commands).
It might be sufficient to just reload the first file that has those problems, with :e!.
Today I installed vim on my new computer and installed a couple of plugins.
When I start vim (with no arguments and with files to edit) I get a lot of verbose output in my console which I never encountered before.
This seems to be something from the vim sourcecode or from a plugin but I couldn't encounter where it comes from and especially why.
I'm interested in tracking down this issue. How can I do that?
I tried searching for some of these lines in my plugin folder but got no results and starting with the -D flag also gave me no hint. Google and SO search also yielded no results for me.
Additionally I tried to disable each plugin seperately but this also failed.
Thanks.
PS: I would like to provide a picture but since the output is more than 150 lines long this is not a good idea since it doesn't seem to be related with a plugin and I don't have enough reputation.
Maybe a very small part of it:
syntaxset FileType
*exe "set syntax=" . expand("<amatch>")
filetypedetect StdinReadPost
...
svn-commit*.tmp
setf svn
Xresources*
call s:StarSetf('xdefaults')
*/app-defaults/*
Remark: This is not representative since it is randomly chosen from the terminal output, I just wanted to give an impression what is going on.
EDIT: This is NOT an error, its just printing out some kind of source code. Everything is working fine otherwise.
SOLUTION: Removing the autocmd line without any further text did the job. Thanks to FDinoff. Debugging with finish is really pleasant.
Some Vim commands, when argument(s) are left off, print all existing such artifacts. This is useful during interactive use, but if you forget to specify the argument in your (plugin / ~/.vimrc) configuration, this has the effect of "printing cryptic code" (an error would be more useful here).
Your output is likely from an :autocmd without arguments. Check your ~/.vimrc and other files read during startup (see :scriptnames).
When running conque in VIM, the warning message prompts out every time:
Warning:
Global CursorHoldI and CursorMovedI autocommands may cause ConqueTerm to run slowly
I found a method to remove the warning is to comment out the warning-function in the conque_term.vim, but I don't think it's a decent and safe way to solve the problem.
I'm new with VIM, so I found no way to identify the source of problem by myself. Could anyone help? Thanks a lot!
One integration point into Vim is through events, which can trigger automatic commands; the Conque plugin itself uses these to implement its functionality. Events like CursorMovedI are fired whenever you type something or move the cursor in insert mode; this can have an impact on performance, and that's what the warning is about.
You can list all such automatic commands via:
:verbose autocmd CursorHoldI,CursorMovedI
As long as Conque works well for you, it's fine to ignore (and suppress) the warning. But if you indeed run into problems, you'd need to check the other autocmd sources and maybe disable one or the other plugin (at least for the Conque buffer). (See :help autocmd-remove for how to do this.)
Off topic, but using Ctrl+Z to drop back to shell and fg to return to vim seems to work way better than Conque. That is if you're using vim from the terminal, which you should.
Some inspiration: http://statico.github.com/vim.html
Sometimes I try a customization/command in my vimrc. Everything seens to be correct, but it just doesn't work.
It's difficult to know what's happening when vim starts, and know which command failed or not, so it's really difficult to debug what can be causing a problem in my vimrc. It's a trial-error approach, which is time consuming and really a PITA. For example, I'm having problems with snipmate plugin in some files and just don't have a clue on how to discover the problem.
Is there a "runtime log" when vim starts, telling which commands it executed, which ones failed and such? This would help me a lot.
running vim with the -V[N] option will do a pretty hefty runtime log, here N is the debug level.
vim -V9myVim.log
would create a log of debug level 9 in the current directory with the filename myVim.log
:messages shows all warnings, errors, and informational messages that appeared (possibly briefly) in the vim statusline.
:echo errmsg prints the most recent error message.
g< is another feature few people know about. From :help g<:
The g< command can be used to see the last page of previous command output. This is especially useful if you accidentally typed <Space> at the hit-enter prompt.
For example try :!ls then cancel the prompt, then hit g<.
Put this function into .vimrc:
function! ToggleVerbose()
if !&verbose
set verbosefile=~/.log/vim/verbose.log
set verbose=15
else
set verbose=0
set verbosefile=
endif
endfunction
Then create directory ~/.log/vim and call ToggleVerbose() to get your log in ~/.log/vim/verbose.log. Note that you may catch «variable nested too deep for displaying» error which will not normally appear just because you have raised your verbose level.
I don't think there is a runtime log, per se, but you can run it in debug mode.
http://web.archive.org/web/20090323034339/http://www.troubleshootingwiki.org/Debugging_Vim_Scripts
This probably goes against everything SO stands for, but here's what I do: I just hit print screen soon as the warning comes up and look at the picture.
I had to add "set nocp" to use "ToggleVerbose()" function when run in root because of &verbose