I'm using vim for LaTeX and I'm using latex-suite. It gives me nice syntax highlighting and folding, but in large files syntax highlighting gets "confused". If I open all folds, the syntax highlighting turns OK. I would like it to "just work" all the time though.
I seem to recall an option that would increase the number of lines that is used as basis for determining syntax highlighting but I cant find it.
I don't edit LaTeX, but perhaps you want ":syn sync fromstart"? Just be warned that this can significantly slow down Vim since it forces Vim to do syntax highlighting parsing for the whole file rather than a section of the file. See ::help :syn-sync".
Ctrl+L in normal mode forces a redraw and often fixes syntax colour problems.
zRzMzx (i.e., expand all folds, contract all folds, fold to show current line) sometimes fixes syntax highlighting problems related to folds
10 years later, this is still somehow an issue. Similarly as Jeromy, I suggest pressing zRzMzzza which stands for
open all folds
close all folds
open (toggle) the fold I'm on
center buffer on this line
It looks like we need to learn to live with this
Related
I've just recently started to use the folding functionality of vim and it's very helpful for the languages that it works really well for.
My issue lies in the way vim comments out the fold markers in scilab code. It defaults to
/*{{{*/ and /*}}}*/
which works great in languages like C, but is not actually a comment in scilab. I get a multiplication error when i try to run the code.
I've tried adding
autocmd FileType scilab set fmr=//{{{,//}}}
to my .vimrc file which doesn't quite do what I'd like. It results in
/*//{{{*/ and /*//}}}*/
which are still not comments. The code "folds" fine but becomes unusable. I could set up a macro to replace every instance of "/*" with "//", but that could have unintended consequences when applied globally to a file.
So the question is: how can i setup vim fold markers comments for scilab files such that it will not render the file unusable?
You do not add the comments to 'foldmarker' itself, there's the 'commentstring' option that influences how Vim surrounds the fold markers (when creating folds with zf). Try setting
:setlocal commentstring=//%s
for your scilab filetype. (Put the command in ~/.vim/after/ftplugin/scilab.vim to make it permanent.)
It sounds to me like vim doesn't understand how SciLab comments work. I'm not sure if vim comes with SciLab syntax logic these days, is syntax highlighted correctly in your SciLab files? If not, you can get the syntax file from here.
Is there a particular reason you want to use marks? They aren't actually needed. If you don't want vim to auto-fold by syntax or indentation level, you can still manually define folds with
:set foldmethod=manual
That lets you select a chunk of text in visual mode and make it into a fold with 'zf'. No marks required.
More info on various vim folding techniques here.
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.
A long time ago there was an editor called MultiEdit. It has a feature which I can not find in all powerful VIM. In MultiEdit I could press some hot key and it would show something like table-of-contents (aka, condensed-mode, aka outline) were I could see only 1st line of all functions (let it be C source) in current file. I could then move cursor to function that I need and after pressing enter, mode will switch to normal and I would be in function that I need. Very useful for those who likes to put many functions in one file. This feature was extremely simple to use: one config option to enter regex for selecting title-lines and one hotkey for mode toggle.
VIM has folding. But this is different. Folding hides parts of files and displays folded-lines-indicator. It is much more difficult to specify what to hide in folds for table-of-content-display: you need to start fold at title-line and end before next title line. This is more complex than simple regex to select titles.
I so much wanted this feature, I even wrote VIM macro to emulate this MultiEdit behavior, even though I don't know VIM that much. I've wrote it in part because it was easier to to learn a new language and write a macro than to figure out VIM folding module complexity.
Unfortunately, after upgrading VIM, this macro now does not work (infinite loop?). I've wrote it long time ago, and what little I did know about VIM is all forgotten and I could not fix it now. (EDIT: I've fixed my script. Thanks to #romainl for the link).
My question is how to get this table-of-content like display in VIM?
This recent vimcast by Drew Neil explains the generalities of folding and this one goes through the process of creating the kind of folding you are (probably) after.
Depending on the language you work with and your coding style, something as simple as
set foldmethod=marker
set foldmarker={,}
and zM can get you a long way:
If you want to customize what information is displayed, the second link above is almost certainly just what you need.
Have a look at ctags and the vim plugin tagbar.
You also check out the vim plugin unite with the extension Unite-Ouline
it gives a behavior quite close to what you describe.
It's not great but have you tried setlocal foldmethod=syntax? It seems to do a decent job in 7.3 on Windows. ...although I just realized that our coding standard has the opening brace for a block at the end of the line rather than on a new line and if I change to having it on a new line it works substantially less well.
Sometimes when I'm working on a project I want to play around with some data. Often times the data is on one line and is huge (>25k characters). I understand I could set nowrap and have this line just run off the screen, but I tend to like set wrap for other reasons. So, as a workaround I want to hide these long lines in a marker fold (e.g. {{{ long line }}}). This works fine but I run into a problem with synmaxcol for some reason. If the folded line exceeds synmaxcol then when I open the file, the syntax highlighting runs over. For example:
However, as soon as I open the fold the syntax corrects itself:
Having to open the fold every time is annoying though. As you can see in this example the line is not actually all that long -- it just exceeds synmaxcol. Since synmaxcol is exceeded at a "string" element, the rest of the file is highlighted as a string (so nothing but a singular double quote will stop it).
Why is this happening and how can I fix it? I've tried this with different syntax files and filetypes and it still occurs. I've also tried it with no plugins, a minimal vimrc (containing only syn on) and a modeline to set fdm=marker:synmaxcol=60 and it still happens.
You can manually enter :syntax sync fromstart to force Vim to rescan the syntax from the beginning of the opened file.
I would suggest defining a hotkey for convenience:
noremap <F5> <Esc>:syntax sync fromstart<CR>
inoremap <F5> <C-o>:syntax sync fromstart<CR>
Now you can press F5 to clean up most syntax highlighting problems.
Also, have a look at Vim's fixing syntax highlighting - wiki page
Moreover reading :help :syn-sync-first might shed some more light on the issue.
UPDATE:
I was able to reproduce this behavior on my machine (I'm running Vim 7.3.429).
However, when I wrapped the fold markers {{{ and }}} in block comments, vim correctly rendered the syntax. You can create appropriately wrapped fold-markers using the zf command. See Vim tips: Folding fun.
Normally Vim picks the correct blockcomment string based on the currently active syntax. However, my Vim is pretty vanilla and didn't recognize Ruby syntax. I could specify autocmd FileType ruby set commentstring==begin%s=end in my .vimrc file to set the proper block comment. See :fold-create-marker for more details.
Another solution is to set synmaxcol=0, which will effectively set it to infinity. This causes Vim to check the syntax of the entire line, no matter how long it is. However, I'm not sure what kind of performance penalty you'll have to pay for that.
It seems to me that Vim's syntax highlighting for Haskell is broken, or very buggy. Multiline comments in Haskell (beginning with {- and ending with -}) are arbitrarily greened-out and un-greened-out. Sometimes dragging the mouse over the commented code causes it to reverse color.
Has anyone else been experiencing this problem?
Vim's syntax highlighting trades off accuracy for performance, by default. To do this, it only examines a certain number of lines before the current position to determine how things should be highlighted. This means that it can sometimes get out of sync.
The different methods it uses to determine how much text to examine can be seen at :help :syn-sync. If you want it to Just Work, use :syn sync fromstart to make Vim consider the entire buffer up to the cursor to determine the highlighting.
This happens with other languages as well, it's just the way vim works. It does not actually use a parser, which would be required to be completely accurate all of the time. Actually, sometimes you may need more than just a syntax parser.
http://vimdoc.sourceforge.net/htmldoc/syntax.html