For some reason the inclusion guard for quickfix filetype plugin doesn't works when its contents changes.
Inserting the following contents on ~/.vim/ftplugin/qf.vim
if exists("b:did_ftplugin")
finish
endif
call input("qf.vim!")
the message from the input() can be seem after issuing :copen.
But despite the include guard was set from the default filetype plugin on $VIMRUMTIME, as shown by :echo b:did_ftplugin and :1verbose setlocal stl, issuing :copen, :cold, :cnew or :helpg helpg also causes the message to be displayed.
This happens without additional plugins and no settings other than filetype plugin indent on
and set nocompatible.
My first guess was that any command refreshing the quickfix window closes the existing buffer and opens a new one. But including the let b:did_ftplugin = 1 after the endif above avoids the filetype plugin reload, as no message is displayed after the first :copen (but the default filetype plugin is completely skipped, as 'stl' isn't set anymore).
What could be the difference on between the b:did_ftplugin set on default filetype plugin and the one set from my home dir?
The quickfix window is mainly a view (window), though (for implementation reasons) it is backed by a Vim buffer. When I :cclose a quickfix window, and then :copen it again, the :ls! command shows an incremented buffer number. I think that explains the behavior you're seeing.
Related
I would like to set up VIM for Cobol development and wanted to have the lines form column 7 to 11 marked so as to indicate the code areas. However, when I added this line of code in my vimrc file it colorized the NERDTree too.
set colorcolumn=7,11,73,80
autocmd VimEnter * NERDTree
autocmd VimEnter * wincmd p
How can I make the NERDTree columns not colorized and keep colorization only on the working file?
With the following line in your vimrc:
set colorcolumn=7,11,73,80
you define a global value for a window-local option which is reused for every new window. It is set for the 1st window, which passes it on to the 2nd window, etc.
Since that specific value for that specific option only is to be applied to Cobol buffers, you are supposed to use Vim's built-in filetype plugin support:
Make sure you have either of those lines in your vimrc:
filetype plugin on
filetype plugin indent on
filetype indent plugin on
See :help :filetype.
Create after/ftplugin/cobol.vim under your Vim runtime. On a typical Unix system, it should look like this:
$HOME/.vim/after/ftplugin/cobol.vim
And add the line below:
setlocal colorcolumn=7,11,73,80
We use :help :setlocal to make sure that the option won't be passed on to other windows.
I use MacVim and in my .vimrc file I have map ,V :source $MYVIMRC<CR> binding that allows me to apply the newest version of .vimrc in a case it was recently modified.
However I noticed that strange things can happen, relaunch can slow down vim and some plugins can start to conflict after pressing ,V, when everything works fine if I just close and relaunch MacVim from the scratch.
I'd be very thankful if you could give me a hint on the reason of this behavior as I'd like to have a possibility to update .vimrc file that will completely clear internal vim state and grab new configuration file
The only viable way to re-apply your config to a pristine Vim is actually to restart it.
But the most likely cause of slow downs is the overuse/misuse of autocommands.
Autocommands are added without checking for existing ones. One consequence is that they tend to pile-up if you don't manage them properly and every individual autocommand corresponding to a specific event is executed when that event is triggered, leading to dreadful slow downs.
Here are the two ways you are supposed to use autocommands in your vimrc:
Method #1
" anywhere
augroup nameofthegroup
autocmd!
autocmd EventName pattern commandtoexecute
autocmd AnotherEventName anotherpattern anothercommandtoexecute
augroup END
Method #2
" near the top of your vimrc
augroup nameofthegroup
autocmd!
augroup END
" anywhere
autocmd nameofthegroup EventName pattern commandtoexecute
autocmd nameofthegroup AnotherEventName anotherpattern anothercommandtoexecute
The idea is to create a group of autocommands that clears itself whenever it is invoked and thus prevents them from piling-up.
In my .vimrc I've put set foldmethod=syntax to enable folding of methods etc. However, I don't like the default that everytime I open a file, the whole thing is folded. Is there a way to enable foldmethod, yet have files unfolded when I open them?
set foldlevel=99
should open all folds, regardless of method used for folding. With foldlevel=0 all folded, foldlevel=1 only somes, ... higher numbers will close fewer folds.
You can put this in your .vimrc:
au BufRead * normal zR
It declares an automatic command (au), triggered when a buffer is read (BufRead), matching all files (*) and executes the zR (opens all folds) command in normal mode.
set nofoldenable
Adding this to your .vimrc will temporarily disable folding when you open the file, but folds can still be restored with zc
In .vimrc add an autocmd for BufWinEnter to open all folds automatically like this:
autocmd BufWinEnter * silent! :%foldopen!
That tell vim to execute the silent :%foldopen! after opening BunWinEnter event (see :h BufWinEnter). The silent %foldopen! will execute foldopen on the whole buffer thanks to the % and will open all folds recursively because of the !. Any eventual error message will be suppressed by silent. (You could get error messages like E490: No fold found if the buffer actually didn't contain any fold yet)
Note: You could use BufRead instead of BufWinEnter but then if the file has a modeline that enables the folding that will override this autocmd. I mean BufRead autocmds run before the modeline is processed and BufWinEnter will run them after. I find the later to be more useful
You can add
set foldlevelstart=99
to your .vimrc file, and it will start editing any new file with all folds open.
If you want a way to have it display unfolded as soon as it is opened, you can use set foldlevelstart=99 as a lot of answers explained.
But, if you just want to see them unfolded, you can just press zi and it will unfold everything. Another, zi will close them back.
You could map it to keys to enable it.
For example,
nmap ,f :set foldmethod=syntax<CR>
Then while in normal mode hit the ",f" key combination
You can open unfolded file when you put set nofoldenable into your .vimrc file.
autocmd BufReadPost * silent! :%foldopen!
This worked best for me. After a buffer gets opened all folds are opened. This opens them to the correct level.
The set foldenable method was not good, because if I choose to close one fold level, it enabled folding again, and folded every thing to 0 level, instead of just going down one level on the one I activated.
I'd like to have the tagbar VIM plugin launch when I open certain filetypes, so I added the following to my .vimrc:
if has("gui_running")
autocmd BufEnter *.hs nested TagbarOpen
However, this isn't working as I expected. It opens a side window, but the side window displays nothing and my cursor is trapped within it. I cannot switch windows with a click or with the CTRL-W movement commands.
However, when I run TagbarOpen manually, it works just fine.
Anyone else tried this, or is the above the wrong command to issue?
Interesting, that's a side effect of a convenience functionality that I hadn't anticipated. What happens is this: If TagbarOpen is called while the window is already open, Tagbar makes the cursor jump to its window instead of just doing nothing (for convenience like I said). So every time you try to leave the window by switching to the Haskell window, the autocommand causes it to jump right back. I've pushed a change that removes this functionality -- it probably wasn't that useful to begin with. So if you give the development version on GitHub a try (https://github.com/majutsushi/tagbar), it should work.
That the window is empty has a different reason: Haskell is not supported by Exuberant Ctags by default. But someone wrote a nice alternative for Haskell that works with Tagbar here: https://github.com/bitc/lushtags.
I actually have this exact configuration set up my vimrc for php files. Tagbar opens with function / variables loaded, cursor stays in php source file when Vim loads:
autocmd FileType php call SetPHPOptions()
function! SetPHPOptions()
setlocal shiftwidth=4 tabstop=4 softtabstop=4 expandtab makeprg=php-xdebug\ %
:call tagbar#autoopen(0)
endfunction
substitute 'php' for 'hs' or any other file type you want. List of filetypes at:
$VIMRUNTIME/filetype.vim
Have it running on MacVim (snapshot 72, Vim 7.4), and latest build of tagbar from https://github.com/majutsushi/tagbar
I'm using the Vim plugin clang_complete and I want to update the compilation errors in the QuickFix window whenever I save the file. So as the doc says, I must call the function g:ClangUpdateQuickFix().
The thing is that the next autocmd gives me the next message whenever it is executed despite it seems to work:
No matching autocommands
The autocmd I use is:
autocmd BufWritePost *.c,*.cpp,*.cxx,*.cc call g:ClangUpdateQuickFix()
What is the meaning of that message?
The displayed message come from clang_complete itself. Some vim plugins (not clang_complete) are reparsing the quickfix window whenever it changes. Fortunately, vim provide an autocmd for that: QuickFixCmdPost, so these plugins are using this to reparse the quickfix messages.
In clang_complete, since we're modifiying the quickfix window and we don't want to break existing plugins, we need to trigger this autocmd manually. What you get is the No matching autocommands message when you don't use those plugins.