I'm using vim now for almost over a month and I am very dedicated to it. But since I added a few plugins, navigating through larger files (400+ lines... especially PHP files) makes vim pretty slow. It doesn't bother me much, because it is still pretty fast.
But I sometimes face the problem that navigating with hjkl hangs and even though I stopped pressing j for instance it keeps going for quite a while which is very annoying.
I run vim in iTerm on my mac and I'm not sure what to do here.
Thank you for any help.
//edit: Okay I found now what causes trouble. Everything that changes the current line style or messes with line numbers causes trouble.
So set cursorline or set rnu nu are causing my vim to lag. I think it is because the "redraw" is a pain for my terminal.
This is absolutely normal.
Some vim plugins are powerful, but not intended to be used handling large files (because it will require an enormous memory usage).
But the solution is simple: Use the LargeFile plugin which automatically detects when the file you are opening is too big and, in that case, disable some plugins and features just for that buffer.
Related
Before set foldmethod=syntax, my vim works like rocket, but everything changed after that, my vim works like tortoise, I can't bear the vim responding time.
so, I decided set foldmethod=indent, but it's not strong and smart enough.
And I try to write some vimscript, but it worths too much, what should I do?
NOTE: I just want to fold my c++ code.
It's hard to tell what's causing this without the problematic source code files. A lot of developers use Vim to edit C++ files (with syntax-based folding), so it's not a general problem. Do you have overly long files, a lot of nesting, or many #ifdefs?
I'm a bit surprised that it's just the folding part of the syntax that slows you down. Usually, it's the whole syntax parsing (on complex files), and only :syntax off can remedy that.
You may want to fiddle with the syntax sync options (:help :syn-sync). Also read :help :syntime; this can help with troubleshooting. I'm afraid there's no quick and easy fix.
A bit old thread, but just in case, try the FastFold plugin, I've been having issues with a large PHP file, and after switching to this plugin my Vim is really snappy. And even other issues with some plugins like Quickjump seem to be gone.
Tip found in this reddit thread
Recently (vimdiff: force line-by-line comparison (ignore supposedly missing/additional lines) ), I've found the quite useful vim plugin diffchar, which improves vimdiff by showing multiple diffs on the same line separated, instead of highlighting the whole area from the first to the last diff.
The problem is that I frequently encounter files where diffchar doesn't work properly, namely spills out a whole lot of errors when vimdiff is opened, plus I think it slows down vimdiff substantially for large files (which I'm dealing with far too often).
Is there a way to disable this (or any) plugin by default?
The plugin already has the functionality to turn it off (toggle it), mapped to F7. What I'd like is that it's turned off by default, but that I'm still able to turn it on (using F7) when I specifically need it. (I'm also fine with tweaking the source file of the plugin accordingly, BTW.) What I've already tried is simply adding the command F7 is mapped to (ToggleDiffCharAllLines) to .vimrc, but this doesn't work.
Just put this into your ~/.vimrc:
let g:DiffExpr = 0
You then have to explicitly enable the plugin via one of its mappings or commands.
I have a file with 400+ lines (it's a thesis). When I edit it somewhere near
the top (say, on line 20), Vim is snappy as always. However, editing it near
the bottom (around line 400) causes a noticeable delay between me typing the character
and Vim showing it on the screen. As a consequence, it is almost impossible to
edit a file this big.
What is the reason for this and what can I do?
I've tried toggling the swapfile, syntax, scrolloff etc, but it doesn't
seem to help. The maximum number of lines for Vim should be 2147483647, so I
should actually have a long way to go here :)
In case this is related to setting maxmem, then what would be a reasonable
value, considering that I edit files up to 2500 lines?
Thanks very much for any help! Cheers.
Okay, folding was the problem here (I had some bad settings for foldlevelstart). So, based on my experiences and these issues:
set foldenable " can slow Vim down with some plugins
set foldlevelstart=99 " can slow Vim down with some plugins
set foldmethod=syntax " can slow Vim down with some plugins
Other things to check/toggle are syntax, filetype, wrap and line length (some plugins can be slow with very long lines).
Running Vim without your current settings is a good starting point. Thanks to #Frederik for pointing me to this:
vim -u NONE
After this, disabling all plugins is a good start. See also for general knowledge: :help slow
I recently came across this exact problem - lag while typing at the bottom of a relatively short (markdown) file. After uninstalling plugins and commenting out most of the settings in my .vimrc, I discovered that the issue was markdown folding coming from the vim-markdown plugin that is pre-installed with vim. Commenting out let g:markdown_folding = 1 did the trick.
I still wanted to have automatic folding on markdown files, so I installed vim-markdown-folding and there are no issues with performance.
In my case relative numbers with same file opened in multiple windows was lagging. I had to do either :set norelativenumber or close another windows.
Don't blame syntax only, several things can slow down editing in normal mode. e.g. auto completion; I had days of thinking that my Vim was slow because of syntax. I configured my autocompletion plugin to only trigger autocompletion once I have typed in at least 6 characters and the speed grew tremendously. I didn't even have to touch anything with syntax highlighting.
The question is self explanatory, but I haven't found a single resource that explains what the difference is after an hour of searching. After poking around a little bit in both, it appears that gVim and gVim easy are identical.
Gvim easy is started and locked in insert-mode (every character you type is printed like a simple notepad).
Standard gvim starts in normal mode and you have to toggle between normal/insert like all other vim.
From help:
Easy mode. Implied for |evim| and |eview|. Starts with
'insertmode' set and behaves like a click-and-type editor.
This sources the script $VIMRUNTIME/evim.vim. Mappings are
set up to work like most click-and-type editors, see
|evim-keys|. The GUI is started when available.
{not in Vi}
gVim-Easy, which is installed with gVim, has all the functionality of
normal gVim but lacks modes. This is especially useful for begginers
and people who do not want to, or do not have the time to, learn how
to use gVim. Users can benefit from gVim's superior syntax
highlighting and auto-indentation while not having to have to learn
the, often deemed complex, command set of gVim in order to edit a
simple document. It is recommended that readers of this tutorial at
least try to learn how to use gVim in normal mode, the learning curve
is steep, but, the benefits in speed and usability this confers is
worth the investment.
Read here
gVim Easy: gvim.exe -y (pass a parameter y)
gVim: gvim.exe
It seems that Insert and Replace are available modes, and command mode is missing. And at first glance it appears to have lost the ability to save a document using keystrokes - the File menu shows only ":w" for Save and without command mode, the command simply isn't there. What isn't shown however is Alt-F followed by S - this works, although also missing is the status line confirmation of the file being written.
Sometimes I hit the wrong keys on my laptop's small keyboard, and odd navigation or editing occurs (sometimes a feature that's new to me).
Although I can undo the editing (u) or navigation (control-o), I don't know what I did wrong, so it's difficult to avoid it in future. It's also frustrating to not know what just happened. So, I would like to be able to see my last few keystrokes.
A bit like :set showcmd, but to show the literal keystrokes, and (ideally) a short history of them.
I've only found commandline and navigation history in help/google.
To clarify: I'm not looking for commandline history, but keystroke history. e.g. did I press ) accidentally and go to the next sentence? Did I press dd and delete a line? I guess it's similar to a keystroke logger.
Commandline history (:history) only shows commands entered at the : prompt.
A bit old, but I've just found this on reddit:
You can start vim with the -w flag to write all keystrokes in a file. See :h -w
vim -w filename
To my knowledge, the closest you can get is the q command, which records your keystrokes into a register of your choice. Obviously, that has to be set up a priori as it's intended for complex repeats, although you could probably hack something to start recording on every file open. There's the matter of memory usage and that annoying "recording" prompt though.
Probably the most straightforward way would be to install keylogging software. I don't have any personal experience with these, but the security implications are probably mild if you get it from a trustworthy source or build it yourself, set it to only log to memory not a disk, only have a buffer the size of a sentence or so, or only log for vim windows.
More recently I came across a logging plugin for Vim and it reminded me of this question:
http://wolever.net/~wolever/wiki/vim-logging
It basically records everything you do for later analysis, it was intended for getting statistics about command usage but should work perfectly for finding what those magic commands you accidentally entered were.
:history will show your command history - that should help you uncover the new features that we all uncover in vim with misplaced keystrokes.
Gundo - Is probably worth a look, whilst perhaps not exactly what you are looking it will help slightly.
It lets you visualise the Vim undo tree, this means you will be able to see the last edits that happened. For example if you accidentally deleted a line or some such this will show up in the tree, however, it doesn't show you the actual keystrokes that were pushed and will not show things such as cursor movements.