Is there any way to stop vim from automatically updating folds on the fly? I really love vim's folding, and I prefer having it in syntax mode so that folds are created as I type. But for instance when I code C++ and I write a bracket { it automatically closes all subsequent folds, and when I then close the bracket again with a }, vim automatically expands all subsequent folds, meaning that I have to refold everything.
Another related problem, if I have the same document open in a different buffer, say I have run ":split", then writing an open bracket { will nest all folds in the buffer under the fold in which I opened the bracket, and closing it will un-nest the folds but also close all of them. If I use either "." or "->" to access a member function/variable, it resets all folds in the buffer to be whatever the current foldlevel is, regardless of which folds I have opened/closed myself.
This is somewhat frustrating when I have the same document open in two buffers so I can read the contents of one function when writing another, as I constantly have to switch buffers and reopen my folds.
In my .vimrc I have
set foldmethod=syntax
and that is about it. For autocompletion I use clang-complete and supertab with:
let g:SuperTabDefaultCompletionType = "<c-x><c-u><c-p>"
I think that is everything which migh affect this.
Edit:
Added some pictures to help illustrate the problem
Both problems can be solved with the following two autocmds:
autocmd InsertLeave,WinEnter * setlocal foldmethod=syntax
autocmd InsertEnter,WinLeave * setlocal foldmethod=manual
This sets the buffer local 'foldmethod' to manual when insert mode is entered or its window (a buffer display) is left, and sets it to syntax when insert mode is left or its window is entered.
This works because setting 'foldmethod' to manual will keep the folds automatically created by syntax as if you set them yourself (manually), and manual folds are not updated based on the syntax of the file.
I've found two bugs with this solution:
When switching windows while in insert mode, the autocmd will set the 'foldmethod' to syntax for the new window, even though it's in insert mode and should be set to manual.
This isn't really a problem for me because I use Vim like a civilized person and operate in normal mode by default.
When
a new buffer is created (e.g. by reading a file)
and 'foldlevel' is 0
and a particular syntax is used (I'm able to duplicate the issue with a C file)
and the o or O command is used to enter insert mode for the first time in that buffer (doing i<esc>o does not duplicate the bug),
then all folds below the cursor will be opened.
I accidentally discovered this when testing the above solution, and now looking back I'm surprised I found it; it's almost not even worth mentioning. I don't intend on trying to write a test file that has the exact syntax necessary to duplicate the bug, so this may go unnoticed for another eon.
I actually discovered this question several months ago and used the solution Ben linked to for a while, before eventually being annoyed enough with the multiple window for one buffer issue (your second problem) to fix it.
So thanks to Ben for his solution, and you for asking this question!
I made a bit of a modification to user4830797's answer which helps deal with situations where the file you're editing doesn't use foldmethod=syntax (for example, a .vimrc file which might use foldmethod=marker):
autocmd InsertLeave,WinEnter * let &l:foldmethod=g:oldfoldmethod
autocmd InsertEnter,WinLeave * let g:oldfoldmethod=&l:foldmethod | setlocal foldmethod=manual
I think you need to check :h 'foldlevel. You should also perhaps use :mkview, probably in autocmd which restores manually open and closed folds.
Other then that you should perhaps set folding method differently on different file types (for instance on C you could set it to manual or marker)
If you temporarily set the foldmethod to manual, then Vim will keep all the folds currently defined by syntax, and keep them in the exact open/closed state you have them in now. This can be done automatically with an InsertEnter autocmd and restored on InsertLeave to protect your fold states in a single window. Unfortunately I have not yet spent time trying to get it working in split windows, but using window-local variables it is easy enough to even account for the user switching windows or something without leaving insert mode. See http://vim.wikia.com/wiki/Keep_folds_closed_while_inserting_text for details and discussion.
Related
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
Is there an autocmd for when the preview window is opened/closed?
I want to scroll the main window n lines up when it the preview window is opened, then n lines down when it is closed, to counteract the "moving text" effect that occurs natively.
Am I able to do this with the relevant autocmd (and what is it), or is there a better way for me to achieve this?
There is no such autocmd event. But you can use WinEnter and BufDelete associated with previewwindow option to achieve something similar.
Using WinEnter you can check previewwindow; if you are on preview window, you can set a buffer variable to differ this event from subsequent events that can be generated by moving to another window and back to preview window. You can also set au BufDelete <buffer> call MyRestoreMainWindow() to call your function when preview window is closed.
I see this question asked often and always scratch my head wondering what is that window-shifting people talk about that I don't experience.
Well, today it occurred to me that two options that I've added to my ~/.vimrc a long time ago have the pleasant side effect of preventing that dreaded window-shifting:
set splitbelow
set splitright
Give it a try!
I was actually wondering the same thing except with the tab bar -- how to prevent that annoying shift from occuring when the tab bar is shown or hidden. Have you considered a wrapper function? The following seems to work for the ps example (it will still cause a shift if the preview window would obscure the cursor)
se splitbelow splitright
fun! PsWrapper(text)
let view=winsaveview()
exe 'ps' a:text
call winrestview(view)
endfun
While we're here ... the tab bar case seems to require some black magic. Ie, as someone pointed out, the tabbar will cause the text to scroll down if the cursor is above the middle line (??). But this seems to work - to always show a tab bar:
let [view,g:stal]=[winsaveview(),&stal]
let [view.topline,&stal]=[view.topline+!g:stal,2]
call winrestview(view)
and to restore the original tabbar setting
let [view.topline,&stal]=[view.topline-!g:stal,g:stal]
call winrestview(view)
You can't really do this with a simple autocmd - Using the WinEnter/WinLeave/BufEnter/BufLeave auto commands all have minor quirks (stated in the vim documentation) so they won't consistently solve your problem completely.
If this happens to you when opening splits, then you can solve this like #romainl suggested, by defining in your .vimrc :
set splitright
set splitbelow
BUT... This will still happen when opening various 'preview' windows, or using the quickfix or location list windows vim has to offer. I use them a lot, and this problem really annoyed me, so I wrote a plugin to solve this.
You can check it out here: https://github.com/gillyb/stable-windows
It works by maintaining state of the cursor position and top line number of the windows open in your vim layout, and restoring them each time you switch to a different buffer.
It's relatively new (as of writing this answer) so if you find any bugs feel free to open an issue, and I will try to address them quickly.
Hope this helps! :)
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.
I'm using c-support in Vim. One of it's features is the automatic comment expansion.
When I'm pasting code into Vim from an external editor, the comments are expanded (which gives me double-comments and messes up the paste - see below for example). I'd like to be able to disable the plugin, paste, then re-enable it, without relaunching Vim. I'm not sure if this is possible.
The SO questions here, here and here all describe methods to disable plugins, but they all require me to close Vim, mess with my .vimrc or similar, and relaunch; if I have to close Vim, I might as well cat file1 >> myfile; vim myfile, then shift the lines internally, which will be just as quick.
Is it possible to disable a plugin while running vim without relaunching, preferably in a way which allows me to map a hot-key toggle-plugin (so re-sourcing ~/.vimrc is alright; that's mappable to a hotkey [I imagine, haven't tried it yet])?
Messed up comments:
/*
* * Authors:
* * A Name
* *
* * Copyright:
* * A Name, 2012
* */
EDIT: It turns out you can :set paste, :set nopaste (which, to quote :help paste, will "avoid unexpected effects [while pasting]". (See the comments).
However, I'm still curious whether you can disable/enable a plugin as per the original question, so I shall leave the question open.
Insert ":set paste" then paste your code. After that insert :set unpaste
There is no general way of doing this without modifying plugin source. Some plugins (like all of mine) can add this feature (I have “unload” feature in my framework, but use it mainly for updating without restarting vim, not for temporary disabling something). What you can definitely do is to add a function call to each sourced plugin file that will save current vim state and also something that will do this after plugin was loaded (due to existance of finish, throw, try | <code with some error> you can’t just add this function at the end of the plugin), likely on VimEnter, FileType and Syntax events. Then you need to have a function that will revert changes done to the plugin and an s:Execute function definition in each plugin, like this:
function s:Execute_I_do_not_expect_function_with_this_suffix_to_be_defined_by_the_plugin_so_I_add_it_to_avoid_name_collisions(s)
execute a:s
endfunction
. This is needed to execute a line of code in the context of sourced script. By “state” that needs to be saved I mean
Mappings
Commands
Signs
Functions
Menus
Events (autocommands)
Syntax (likely to be empty before plugin run)
Options
Some vim, all global, buffer, tab and window variables
// Script-local variables. Though it is simple here: at the start of the script script-local scope is empty and all you need is to empty it when disabling.
For each item it is possible to revert changes done by plugin, but it is not that easy to code. And presence of <script> argument to mappings is not distinguishable with presence of nore, though they have different behavior.
If you want to write it, do not forget about the fact that if script is resourced, your code will be relaunched.
Also, note the SourcePre event. It will help with automatic addition of your lines to all plugins.
Do not forget that there are more places that can be modified and can’t be saved and restored easily or at all: filesystem, interpreters state, opened plugin buffers, etc.
I am using several languages, and currently I am obliged to indicate to vim with which of these the spell check must be done. Is there a way to set up vim so that it automatically detects the correct one? I vaguely remember that in a previous version of vim, when the spell check was not integrated, the vimspell script made this possible.
It would be even better if this could apply not only to a file but also to a portion of a file, since I frequently mix several languages in a single file. Of course, I would like to avoid to load several dictionaries simultaneously.
I don't know if there is a way to autodetect it, but if you put vim:spell:spelllang=foo,bar,baz at the bottom of the file, vim will set the spellchecking languages to foo, bar, and baz when the file is opened. Note that you must put at least one space before that text, or vim will think it's part of the file.
Since vim is missing this feature, I found it useful to define shortcuts like these in .vimrc:
command! Nb :set spelllang=nb
command! En :set spelllang=en