I'm using VIM 7.1 on Debian. I have 9 plugins that I load via pathogen.vim. It takes around 8 sec's to load which is quite slow since this is in non-GUI/xterm mode. I ran vim -V and it shows that each module is being searched for in multiple directories.
Initially, ftoff.vim, debian.vim and other "system" related .vim files are searched for in ~/.vim/ and then in /usr/share/vim/vim71/ - I fixed this by moving my .vimrc to .vim/vimrc and: export VIM=/root/.vim, within .vimrc i did a set runtimepath=/usr/share/vim/vim71
But now, when the modules load, they alter this runtimepath and when pathogen loads it's even worse. Is there a way to specify a hash of module-name to dirPath so that this error prone lookup is avoided? Or a way to manually specify runtimepath on a per module basis within vimrc?
Here is an example of my runtimepath after pathogen loads my modules. Obviously, any further loading of a module invovles searching all those pathnames before locating the right path.
runtimepath=~/.vim,~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bu
ndle/The_NERD_Commenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/pathogen,~/.vim/bundle/vim-addon-mw-utils,
/.vim/bundle/tlib,~/.vim/bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist
~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bundle/pathogen,~/.vim
bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist,~/.vim/bundle/The_NERD_C
mmenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/tlib,~/.vim/bundle/vim-addon-manager,~/.vim/bundle/vim-add
n-manager-known-repositories,~/.vim/bundle/vim-addon-mw-utils,/var/lib/vim/addons,/usr/share/vim/vimfiles,/u
r/share/vim/vim71,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/bundle/snipMate/after,~/.vi
/after,~/.vim/bundle/snipMate/after
I use vim-addon-manager and have 33 paths in rtp, but it takes around 0.7-0.8 seconds to start and immideately close vim (with vim -c 'qa!'), so the problem is either one of the plugins or your system. To check how long it takes to load each plugin, try the following script:
vim --cmd 'profile start profile.log' \
--cmd 'profile func *' \
--cmd 'profile file *' \
-c 'profdel func *' \
-c 'profdel file *' \
-c 'qa!'
You will get all timings in the profile.log. Table with function timings will be
present at the end of the file, to get per-script timings, use the following
script:
" Open profile.log file in vim first
let timings=[]
g/^SCRIPT/call add(timings, [getline('.')[len('SCRIPT '):], matchstr(getline(line('.')+1), '^Sourced \zs\d\+')]+map(getline(line('.')+2, line('.')+3), 'matchstr(v:val, ''\d\+\.\d\+$'')'))
enew
call setline('.', ['count total (s) self (s) script']+map(copy(timings), 'printf("%5u %9s %8s %s", v:val[1], v:val[2], v:val[3], v:val[0])'))
This will open a new file containing just the same table as at the end of
profile.log, but 1) for scripts, not for functions, 2) unsorted.
If problem is your system, you may try the following:
When computer starts create a ram disk and mount it to ~/.vim, then copy all plugins there.
Try merging plugins into a single file, see :h scriptmanager2#MergePluginFiles() (vim-addon-manager must be activated)
Upgrade your computer
Try creating a hardlinks to all plugins in ~/.vim:
cd ~/.vim/bundle;for d in *;do cd "$d";for f in **/*.vim;do t="$HOME/.vim/$(dirname "$f")";test -d "$t"||mkdir -p "$t";ln "$f" "$t";done;cd ..;done
it might not be related, but for me the variable DISPLAY makes a big difference in the time it takes to start vim (even when I have vim compiled without gui).
Try with
DISPLAY= vim
and
DISPLAY=:0 vim
and see if you notice a difference.
http://pastebin.com/R6E4czN7
I've pasted the output of vim -V to pastebin (should be valid for 1 month). It's self explanatory. There are a gazillion searches(414 search lines - most of them are useless). I need to reduce the number of incorrect searches.
1297651453.71068: Searching for "/root/.vim/bundle/pathogen/autoload/scriptmanager.vim"[J
1297651453.71456: Searching for "/root/.vim/bundle/snipMate/autoload/scriptmanager.vim"[J
1297651453.71846: Searching for "/root/.vim/bundle/SuperTab/autoload/scriptmanager.vim"[J
1297651453.78737: Searching for "/root/.vim/bundle/surround/autoload/scriptmanager.vim"[J
1297651453.79179: Searching for "/root/.vim/bundle/taglist/autoload/scriptmanager.vim"[J
1297651453.79684: Searching for "/root/.vim/bundle/The_NERD_Commenter/autoload/scriptmanager.vim"[J
1297651453.80756: Searching for "/root/.vim/bundle/The_NERD_tree/autoload/scriptmanager.vim"[J
1297651453.83: Searching for "/root/.vim/bundle/tlib/autoload/scriptmanager.vim"[J
1297651453.86193: Searching for "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.8662: line 3: sourcing "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.88259: finished sourcing /root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim[J
Related
I'm trying to use astyle as my code formatter in Vim. However, I can't seem to find how to tell vim which options to use for astyle.
The following is in my vimrc:
autocmd BufNewFile,BufRead *.cpp set formatprg=astyle\
If given no options in command line mode, astyle will try to find an options file named .astyle. However this does not seem to work here. (Ie: when I format in vim: gqG the result is totaly different than if I had called astyle from the command line !)
This is my .astyle options file:
--style=allman
--mode=c
--attach-classes # -xc
--attach-closing-while # -xV
--indent-classes # -C
--keep-one-line-blocks # -O
--keep-one-line-statements # -o
--align-pointer=name # -k3
So I tried to simply specify the options in my vimrc like in this answer:
autocmd BufNewFile,BufRead *.cpp set formatprg=astyle\ --style=allman --mode=c -xc -xV -C -O -o -k3
Saved, sourced, reloaded vim entierly: no change. The options seem to not take effect. When I format with gggqG the result is still not what my options ask for... Can anyone see why this is not working ?
(Note: I want to be able to format using gq and I don't mind reformatting the whole file entierly each time, unlike in this question)
EDIT:
After a few stupid mistakes I've escaped all the spaces as suggested in #romainl comment. However there seems to be an error comming from vim which I cannot interpret:
/bin/bash: -c: line 1: syntax error: unexpected end of file
shell returned 1
E485: Can't read file /tmp/vHXZmnp/3
Since no one is answering, I'll share what I managed to come up with.
Following the advice given in the comments I escaped all the spaces in the sequence of options passed to astyle. However, this leads to bash trying to interpret the options, failing and kindly telling us so: see question edit.
The solution that seems to work is to create a system wide astyle options file and pass the path to that using command line arguments instead of giving it the options directly.
(This can probably also be done with a project options file but requires having an options file at the root directory of every project)
Taking my options file .astylerc in my home directory this gives:
autocmd BufNewFile,BufRead *.cpp set formatprg=astyle\ --options="/home/myusername/.astylerc"\
Note that a relative path did not work, but it is possible to write the path to the options file using a 'pseudo relative' path using the $HOME environment variable as mentioned in the astyle documentation
I frequently send files to Vim from Visual Studio. I have it set up as an external tool with the following parameter:
"+call cursor($(CurLine), $(CurCol))"
However, I also want to be able to call my own function as well. When I'm editing a file from VS I want the window to be large, so I expected to be able to do something like this:
"+call cursor($(CurLine), $(CurCol)); +call Embiggen()"
However, that doesn't work. I've tried a few variations (e.g. , call Embiggen(), etc).
Obviously I could write my own PlaceCursorAndEmbiggen function, but I don't really want to do that. Is there any way to call multiple functions on Vim startup?
Eureka!
Simply pass two strings:
"+call cursor($(CurLine), $(CurCol));" "+call Embiggen()"
Maybe the solution would have been easier to find had you used the alternative, more commonplace syntax: -c "cmd" instead of "+cmd". According to :help -c, you can pass up to 10 of these.
These exact commands can be combined into one using pipe symbol:
"+call cursor($(CurLine), $(CurCol)|call Embiggen()"
. There are much more that can be combined this way, but some like :normal can’t, use #Ingo Karkat’s or your own answer for them. If you are short* on +commands and still don’t want to create a .vim file you can use either :execute
vim -c "execute 'normal! 1' | execute 'normal! 2'"
or (bash/zsh) -S with process substitution:
vim -S <(echo '
normal! 1
normal! 2
')
. Though most of time it is better to just create a .vim file.
* You can pass up to 10 + or -c (they are equivalent and they are not counted separately) and 10 other --cmd, though letter is less useful.
I am trying to open a 200MB text file in gvim on Windows, and it's choking. The vim window opens and just remains blank and unresponsive. My system has 8GB of RAM and the file opens fine in about 2-5 seconds using notepad.
I found this SO post on editing very large text files in vim, and I tried opening the file with plugins turned off:
vim -u "NONE" my200MBfile.text
But that didn't help. Is there anything else I can do to make it work? It seems strange that vim would choke on my machine on what is not really such a large file.
Thanks!
Most likely it's the syntax plugin that makes vim halt. I never have any issues with files of Mbs-Gbs. Unless I accidentally open them with some - not-so-well-behaved - filetypes.
Press ^C while loading/hanging (interrupting plugins)
:syntax off
Does the trick. There are other options with syntax that makes it easier to work with a file without fully 'synchronized' syntax highlighting
I played around with this some more, and I found indeed some of my plugins would make operating on (very) large files very slow. I did this, for fun:
On a large input file (~600Mb):
$ wc input.txt.full
2674568 2674568 608825278 input.txt.full
I launched vim with the following tweaks:
vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full
Note this
-u NONE prevents execution of initialization (user) scripts and plugins
-n disables the writing of swapfiles (extremely important on slow/small disks)
se nonu nowrap ul=-1 disables
line numbering
line wrapping
undo history (setting undolevels to a negative value)
Basically, everything that could take a lot of CPU or memory
syn off to disables syntax highlighing (should only make a difference if syntax highlighting was in effect for the file type)
Now, I wanted to duplicate each line on the line itself (globally: copy line, join with previous):
:g/^/t.|-j
Unfortunately, the file would become too large for available memory (~3Gb)1 so I opted to act on the first 20% (~535,000 lines):
:exec "norm 20%"|1,.g/^/t.|-j
This works in a "jiffy" and without problems. Manual navigation (jumps, scrolling, mode switching, searching etc.) seems to be responsive.
Commandline Benchmark:
$ xxd -c 44 /dev/urandom | head -n 3800000 > input.txt.full
$ wc input.txt.full
3800000 91820644 627000000 input.txt.full
$ time vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full +'exec "norm 10%"|1,.g/^/t.|-j' +wq
real 0m7.778s
user 0m6.680s
sys 0m0.952s
$ wc input.txt.full
3800000 101002757 689940307 input.txt.full
(Note that 689940307 ÷ 627000000 = 110.03 %, so that is exactly right).
This isn't slow in my book. For comparison, the wc invocation itself takes the same amount of time (7.7s).
1 All test performed on tmpfs to avoid cache differences.
The problem is more likely that vim doesn't like lines that long very much.
Try using a tool like json_reformat on the file first...
If you absolutely have to edit the file as-is, try :syntax off and possibly :set nowrap before you :edit the file in question.
Although Vim doesn't have a problem opening files of that size (or bigger), it is mentioned that it has a problem of opening a file with, as is your case, only one line (of that size).
You could try various workarounds, but I would suggest going with the "right tool for the right job" approach, and try EmEditor, a text editor made specifically for editing large files (amongst other things).
Note that this is not Vim bashing, but Vim is an editor for editing source code mostly. An excellent one at that, but like every other tool it has its limitations.
As vim doc said, I can use the -b option to open a binary file.
-b Binary mode. File I/O will only recognize <NL> to separate
lines. The 'expandtab' option will be reset. The 'textwidth'
option is set to 0. 'modeline' is reset. The 'binary' option
is set. This is done after reading the vimrc/exrc files but
before reading any file in the arglist. See also
|edit-binary|. {not in Vi}
I use this command to open vim:
$ vim --cmd 'set et' -u NONE -b
I type this command to view options:
:set et? bin?
expandtab
binary
The et(expandtab) option wasn't reset. Why?
Thanks for your help!
Well the issue is, simply, that --cmd -c or +cmd arguments are executed after processing the other flags. This makes sense, as it would not effectively do anything otherwise.
:verbose set et?
would tell you exactly that. In case you need a workaround for your particular sample vim +'set binary' (unlikely since et != binary)
You are right on the docs for --cmd. So it comes down to the order in which command line flags are interpreted, which is basically 'undefined'. Although
This is done after reading the vimrc/exrc files but before reading any file in the arglist
could be taken to imply 'before processing other command line arguments'.
Note The '+' commands essentially go with specific files and are (AFAICT) processed in the order in which they appear, even when intermixed with filename arguments.
I have a number of very long and complex Vim configuration files, but these seem to be causing some unpredictable performance slowdowns.
Is there a way of producing a logfile of Vim's internal activity (in the style of verbosefile) which also includes timestamps for each function call to allow me to debug these issues. Alternatively, are there any other tools to help me in this task?
One thing you can try is invoking vim with --startuptime some_file. This will dump the steps performed during startup, along with timestamps. Try :help --startuptime for some more information.
Unfortunately, this shows you timestamps for files, not functions. If you want to see how long a specific function takes, you could put a call to it in a file under the plugin directory, so it's executed on boot. This won't be possible in all cases and it won't give you a lot of granularity, but it might help you narrow down the problem. Someone else might have a better idea, but I'd start by trying something like this.
EDIT:
I just found two things that may help with this problem. One of them is reltime(). Here's an example from vim's help:
let start = reltime()
call MyFunction()
echo reltimestr(reltime(start))
All it does is show the time a function takes to execute. Combined with, for example, Decho, this could provide a simple log of said functions.
The second one should be a lot more powerfule, the :profile command. It lets you profile a piece of vimscript and place the results in a file. :help profile should tell you all you need to know. Unfortunately, it's only available with the +profile feature, which seems to be enabled only in the "huge" feature set. If your vim doesn't have it, you'll need to recompile. If that's a problem, or you don't want to bother, you might be able to achieve good results with reltime alone.
If --startuptime does not fit your needs, you may use the following command:
vim --cmd 'profile start profile.log' \
--cmd 'profile func *' \
--cmd 'profile file *' \
-c 'profile pause' \
-c 'qa!'
(replace --cmd with -c and add -c 'Command that causes slowdown' if problem occurs not at startup). You will get all timings in the profile.log. Table with function timings will be present at the end of the file, to get per-script timings, use the following
script:
" Open profile.log file in vim first
let timings=[]
g/^SCRIPT/call add(timings, [getline('.')[len('SCRIPT '):], matchstr(getline(line('.')+1), '^Sourced \zs\d\+')]+map(getline(line('.')+2, line('.')+3), 'matchstr(v:val, ''\d\+\.\d\+$'')'))
enew
call setline('.', ['count total (s) self (s) script']+map(copy(timings), 'printf("%5u %9s %8s %s", v:val[1], v:val[2], v:val[3], v:val[0])'))
This will open a new file containing just the same table as at the end of profile.log, but 1) for scripts, not for functions, 2) unsorted.
Better late than never? I was searching to see if I could get vim to include some timestamps in the &verbosefile, as it causes vim to append to the file with no indication of when the appending started.
I adapted the solution from ZyX's answer here and after trying some things out, found that a simple echo "foo\n" will append foo and a newline to the &verbosefile:
let s:VerboseLS = ' **** V'.'E'.'RB'.'OSE LO'.'GG'.'ING S'.'TA'.'RTED ****'
let s:VerboseLE = ' **** V'.'E'.'RB'.'OSE LO'.'GG'.'ING E'.'ND'.'ED ****'
function! ToggleVerbose()
let l:timestamp = strftime("%c")
if !&verbose
let l:msg = "\n\n" . l:timestamp . s:VerboseLS . "\n\n"
set verbosefile=~/.vim/log/verbose.log
set verbose=100
echo l:msg
else
let l:msg = "\n" . l:timestamp . s:VerboseLE . "\n"
echo l:msg
set verbose=0
set verbosefile=
endif
endfunction
nnoremap <silent> <Leader>vl :call ToggleVerbose()<CR>
Now I get nice banners in my log:
Sun Feb 17 14:18:02 2013 **** VERBOSE LOGGING STARTED ****
...[snip]...
Sun Feb 17 14:18:08 2013 **** VERBOSE LOGGING ENDED ****
I defined those banners the way I did so that if I source that script file while verbose logging is on so if I search the log for "VERBOSE LOGGING" or similar I won't match on them.
So, you could adapt this method to use reltime if your vim has('reltime') for sub-second precision and maybe make a timing wrapper to call that echos the start/end times for function calls (although you'd have to refactor when you call things inline without the call command).
Ooh, I just had an idea... I wonder if &verbosefile can be set to a named pipe that goes to util that prepends time stamps... Let's see...