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).
Related
I have installed this plugin for metter bookmark management. It actually does work but I am having problems with the used symbols.
The installation says to check :echo has('signs') to work correctly. If it returns 1, which it does for me, it is working correctly.
:set encdoing is set to latin1 and I am getting the error E239: Invalid sign text: <something>.
I believe that this is an encoding issue. I have also tryed ut8, but the same problem occures.
call s:set('g:bookmark_sign', '⚑')
call s:set('g:bookmark_annotation_sign', '☰')
This is what the symbols should look like. The font I am using is Consolas.
If this issue has already being posted on the issue tracker and it bothers you so much that you don't want to wait for the solution, then you should try and fix the problem yourself and open a pull request.
I doubt anyone on SO is going to the trouble of understanding that plugin, setting-up an environment to reproduce the problem and investigate it further.
As the plugins probably works for most of its users, you could first check if the problem is related to some plugin or setting that you are using. To do this you could follow the procedure described on Vim-FAQ 2.5. Some relevant parts follows:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
If the problem does not occur, when only loading your .vimrc file, the
error must be caused by a plugin or another runtime file (indent
autoload or syntax script). Check the output of the :scriptnames
command to see what files have been loaded and for each one try to
disable each one by one and see which one triggers the bug. Often
files that are loaded by vim, have a simple configuration variable to
disable them, but you need to check inside each file separately.
Obviously you will have to adapt the procedure to always have the bookmark plugin loaded; you can use :scriptnames to ensure that it is actually loaded (you should probably retain your plugin manager, if you are using one).
If the bookmark plugin is the only one loaded and you have no custom settings and it still doesn't work them you probably have a problem with your Vim/gVim installation.
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!.
I am using Vim 7.3 with a great deal of plugins, mainly for PHP development. The omnicompletion works well, apart from a small glitch I've come across. I'm trying to work out whether this is a bug in Vim or a problem with my set up, so here's the situation:
I use set tags=<files> to specify the ctags files that I'm using.
:set tags=/home/jon/.vimtags.php,/home/jon/project/.vimtags.php
If I then print the contents of tags, I get what I expect to:
:set tags?
tags=/home/jon/.vimtags.php,/home/jon/project/.vimtags.php
I can also use omnicomplete as usual, with <C-x> <C-o>. This is, until I try and complete with something that doesn't exist (i.e. an unknown tag that returns no results). I get the "Pattern not found" error message and then, bizarrely, my tags file list is cleared. If I print the contents of tags straight after, I get:
:set tags?
tags=
I've done a great deal of grepping on the Vim plugins that I'm using but, as far as I can see, none of them are setting the tags files anywhere.
Can anyone tell me whether this is due to something in my set-up or a bug in Vim itself? Or even whether anyone else finds the same issue?
I can confirm that this isn't default Vim behaviour - it was being caused by the indexer plugin. For some reason, there was a function that reset tags when the omnicomplete failed. I'm going to contact the developer about this, and see if he can come up with a solution.
If I open a file containing 5,000 lines of code and continue to input, I found that my vim became very slow, it displays my input after about 1s.
It even won't become any better after I start up with --noplugin. But after switching my .vimrc file, everything gets fine again. The .vimrc file is written by myself and after checking for some time, I still can't locate the error. I have clear all the key maps, but the problem still exists.
So can you give my any advise or tell my how to debug in vim? I found there is a debug option but can't get how to work.
You can use the --startuptime option when start vim:
--startuptime {fname} *--startuptime*
During startup write timing messages to the file {fname}.
This can be used to find out where time is spent while loading
your .vimrc, plugins and opening the first file.
When {fname} already exists new messages are appended.
(Only available when compiled with the |+startuptime|
feature).
Take following steps to diagnose the problem:
type vim --startuptime log.txt main.java in bash to start vim
type :tabe log.txt in vim to view the log.
The reason for slowness is often the not set or wrong set ruby_path on compile time of vim (see also discussion on google vim/ruby google group). It is easier to set it in vimrc, because you can change it without recompiling vim. You can set the path through the g:ruby_path variable in your .vimrc file. Don't copy and paste both, use the right one.
If you setup RBENV you have to use this one:
" ruby path if you are using rbenv
let g:ruby_path = system('echo $HOME/.rbenv/shims')
If you setup RVM you have to use this one:
" ruby path if you are using RVM
let g:ruby_path = system('rvm current')
You can also use the vim-rbenv plugin, which sets the path too.
For me the part on loading ruby specific functions in vim got 10 times faster.
If you are using jruby, than the start up slowliness can be even bigger. See examples for fixing it here.
If running vim 7.4,
put this in your .vimrc
set regexpengine=1
vim 7.4 has a new regex engine that appear not to work well in some situations. Previous version vim 7.3 used the old engine ( set regexpengine=1 ).
The "slow response" from syntax highlighting problem affects the vim help files as well ( and .vimrc file too ).
Something like this is usually caused by syntax colouring. Try with :syntax off.
Add these lines to your ~/.vimrc or ~/.config/nvim/init.vim:
set lazyredraw " don't redraw everytime
set synmaxcol=128 " avoid slow rendering for long lines
syntax sync minlines=64 " faster syntax hl
Also if you're using tmux, consider adding this to your ~/.tmux.conf:
set -sg escape-time 10
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