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 want to disable syntax highlighting for a particular programming language. I'm currently using this
au FileType foo syntax off
however this has the problem that it disables syntax highlighting for any new buffers that I open in the same window, even when they have different filetypes. Is it possible to disable syntax highlighting only for this filetype? (e.g. any other buffers in the same window that has different filetype should have syntax highlighting enabled)
One of the things that could solve this problem is to create a syntax/foo.vim file that doesn't highlight anything, but I'm not sure how to implement this when foo is one of the languages that vim highlights by default.
au FileType foo setlocal syntax=OFF
If you want to isolate the config a bit, create a file called ~/.vim/after/ftplugin/foo.vim and put this in it:
setlocal syntax=OFF
This is my .vimrc:
set tabstop=2 softtabstop=0 shiftwidth=2 smarttab
set number
map <F5> :tabp<CR>
map <F6> :tabn<CR>
map <F7> :e %<.cpp<CR>
map <F8> :e %<.h<CR>
map <C-F7> :e %<.vs<CR>
map <C-F8> :e %<.fs<CR>
map <F9> :w<CR>:!./m<CR>
map <F10> :w<CR>:!./%<CR>
let &path.="/home/dirk/projects/dirk/common,/home/dirk/projects/dirk/sp33d,./proj/tmp,./shaders,"
au BufRead *.fs set ft=
au BufRead *.vs set ft=
" Show tabs in light color
hi GroupTabs ctermfg=lightgray
match GroupTabs /\t/
set listchars=tab:>-
set list
My post is about the "Show tabs in light color" part. When I open a file with vim, it does this graying out of the tabs correctly.
However, I like to use multiple tabs, so when I open extra files with the :tabe command or with the -p parameter when starting vim, the graying out of the tabs only works on the first tab, not on other tabs.
I tried opening the files on the other tabs alone and then it works.
Is there something about tabs I don't know? Is there a way to make the graying work on the other tabs as well?
The files I usually work on are cpp, h, py, lua, html, css, ..., they all have this issue, so I guess it has nothing to do with file type specific syntax highlighting?
Any help is appreciated.
Is there something about tabs I don't know?
At least two things:
they are not "tabs" but "tab pages",
your problem is not related to tab pages.
Is there a way to make the graying work on the other tabs as well?
The very first sentence of :help :match is:
Define a pattern to highlight in the current window.
which means that your :match command only impacts the current window and won't have any effect on other windows. Since :tabedit and friends create new windows there's no reason whatsoever to expect your :match to work there too.
For custom matches to work across windows, you need to use :help matchadd() in an autocommand:
augroup CustomMatches
autocmd!
autocmd winEnter,BufEnter * call clearmatches() | call matchadd('GroupTabs', '\t', 100)
augroup END
But…
Vim already has an highlight group for those leading tabs:
hi SpecialKey ctermfg=lightgray
so there's no need for any of that in the first place.
I am a new vim user and trying to turn on syntax coloring for vim on Mac OS X. I followed http://vim.wikia.com/wiki/Turn_on_syntax_coloring_in_Mac_OS_X's instructions, and my ~/.vimrc file has the following content
set term=builtin_ansi
filetype plugin indent on
syntax on
And the text above in ~/.vimrc is highlighted perfectly fine. However, whenever I use vim to edit a current text file or create a new one, I only see black and white text, and manually calling :syntax on does nothing. Any help is apprecaited!
You can use the :highlight command to list all defined groups (according to your colorscheme). A plain text file probably has no filetype and therefore no syntax assigned; you want to try this with any programming language (e.g. *.py or *.c) to see syntax highlighting in action.
Your ~/.vimrc looks fine. (Do you really need the :set term, though?!)
You should remove that useless line:
set term=builtin_ansi
Do you use the default Vim? What filetypes are you editing?
When I open up a file in macvim it is like this http://imgur.com/a/3cLqB#0.
I have set ,V to :source ~/.vimrc<CR>.
After I have this file open, I press ,V, and the syntax highlighting changes to this http://imgur.com/a/3cLqB#1.
The difference is that (,),;,, become from blue, white, and ->,.,? become from blue, darker blue.
Why does that happen? This is my vimrc file https://gist.github.com/pvinis/4979592
--
Update: I found out that Valloric/vim-operator-highlight is the plugin that changes the colors. so the first picture is the correct picture.
I also found out, that as soon as i do :syntax on, the colors reset. Is there a way to check if syntax is already on?
Problem:
When reloading .vimrc, some highlight groups are messed up.
It depends on what plugins you have and what colorschemes you are using.
I've noticed that some highlight links were broken, and some highlight groups were cleared.
Affected highlight groups
In my particular setup I've noticed broken hi links or cleared groups on:
SignColumn
GitGutter (which uses SignColumn)
powerline-status (which uses status line)
Notice the affected areas after reloading:
(reloading means saving the modified file. Using :wa in this example)
Solution
Unfortunately the listed answers or any combination of options that I've tried does not preserve or reinstate the hi groups after reloading.
Running manually colorscheme <your-coloscheme> after reloading fixes everything, but when doing it with Vimscript it does not.
Hopefully someone will share a proper solution to this annoying small issue.
Ugly hack
Reloading vimrc:
On any change to my vim config files, I execute reload.vim:
.vimrc:
" .....
augroup reload_vimrc " {
autocmd!
autocmd BufWritePost ~/.vim/*.vim,~/.vim/vimrc source ~/.vim/reload.vim
augroup END " }
reload.vim: restores broken links and cleared groups
What we have to do is to reinstate the hi groups after sourcing vimrc.
To find the correct values for an affected area, e.g. for SignColumn, type:
:hi SignColumn, BEFORE any reloading has occurred.
The outcome is (where xxx is a preview):
You have to do this for every affected hi.
In the following snippet I initially fix SignColumn to match my solarized colorscheme.
Then I fix some GitGutter color issues:
e.g., GitGutterAdd is linked to GitGutterAddDefault which is preserved, but from GitGutterAddDefault to DiffAdd is broken, so I reinstall that one. And so on so forth.
reload.vim:
source ~/.vim/vimrc
hi SignColumn ctermfg=12 ctermbg=0 guifg=Cyan guibg=Grey
" GitGutterAdd -> GitGutterAddDefault (preserved)
hi link GitGutterAddDefault DiffAdd
" GitGutterChange -> GitGutterChangeDefault (preserved)
hi GitGutterChangeDefault ctermfg=3 ctermbg=0 guifg=#bbbb00
" GitGutterDelete -> GitGutterDeleteDefault (preserved)
hi GitGutterDeleteDefault ctermfg=1 ctermbg=0 guifg=#ff2222
" GitGutterChangeDelete -> GitGutterChangeDefault (preserved)
" (which we already fixed above)
" Powerline highlight groups
" (see this attached Gist for solution)
Everything works as it should:
Fixing powerline-status colors:
This one is a bit more tricky, but the principle is the same. All highlight groups of powerline start with Pl_. But some of them might not exist yet. For example, if you haven't entered visual mode yet, then the respective groups for visual mode won't be populated yet. So, enter insert, visual, and normal modes to populate the groups and then copy them. You can find them at the bottom of the output of the hl command. Then, paste them in your reload.vim and adapt them to be legit hl commands.
It may sound like a lot of work but it isn't.
Here's a gist with the full reload.vim, and some gifs to guide you through.
I had something very similar to this happening. I was able to solve it by making sure these were in the correct order:
syntax on
let g:solarized_termtrans=1
let g:solarized_termcolors=256
set background=dark
colorscheme solarized
I also used this for reloading
augroup reload_vimrc
autocmd!
autocmd BufWritePost $MYVIMRC source $MYVIMRC
augroup END
With those two I could do live updating of my vimrc without having to reload. I am using iTerm2 with Terminal vim. Hopefully this helps someone else out as I have spent quite a bit of time trying to get this live reloading working. Also make sure you have the newest versions of the solarized theme. I know it seems mundane to mention but it might make a difference.
I guess that the highlightings are defined / changed by some plugin. The re-execution of :colorscheme resets those definitions. The plugins would have to hook into the ColorScheme event with an :autocmd, but most don't.
To work around this, try wrapping the :colorscheme in a guard:
if ! exists('g:colors_name') || g:colors_name !=# 'Tomorrow-Night-Eighties'
colorscheme Tomorrow-Night-Eighties
endif
This works for me
"auto reload vimrc once changed
if has("autocmd")
autocmd! BufWritePost .vimrc source $MYVIMRC
" This fixes the color changes and things not working :D
autocmd! BufWritePost .vimrc filetype plugin indent on
endif
I have absolutely no idea why, (probably for the same reason that doing :source ~/.vimrc manually works) but for me replacing
autocmd BufWritePost *vimrc,*exrc :source %
with
autocmd BufWritePost *vimrc,*exrc :call feedkeys(":source %\<cr>")
fixed the problem.
autocmd BufWritePost *vimrc,*exrc :call feedkeys(":source %\<cr>")
Fixed it right away for me. Must be some weird issue with the ordering. I also have a keystroke to resource the file and this always works even when the autocmd was failing.
Most likely unrelated to your particular case, but I had a similar problem so I thought I'd share since it's the first StackOverflow result on Google.
My issue with reloading was in two phases: using the dark Solarized theme, reloading .vimrc would first change the colors slightly, then, reloading a second time, it would switch to the light Solarized theme.
The lines about colors in my .vimrc were:
set background="dark"
let g:solarize_termcolors=256
colorscheme solarized
The problem? The first line shouldn't have quotes:
set background=dark
I can now reload .vimrc without changing the colors. I'm not sure why it would work one time and work a different way after though. I realized that after commenting out everything but these lines as others have suggested.
set syntax enable after colorscheme