I have this in my .vimrc:
highlight ColorColumn ctermbg=234 guibg=#2c2d27
let &colorcolumn=join(range(81,999),",")
When I search for words that fall into this range, the background color for the word does not show up. How do I fix this?
Unfortunately, you can't. The priorities of search highlighting and hlsearch are fixed, you can only specify the priority when using matchadd(), but even with a high number there, I wasn't able to override the 'colorcolumn'. It appears that this is completely separate (like syntax highlighting), and cannot be overruled.
Anyway, the colorcolumn is meant to be a single (or multiple few) columns, not the broad area you've created with your range() trick. So in a way, you're suffering under your own cleverness: You've misused a built-in feature, and now complain about the side effects.
So, move back to a single colorcolumn, or use the emulation used in older Vim versions, matchadd() with a low priority:
:call matchadd('ColorColumn', '\%>80v', -10)
Related
I am running vim 7.3 on several machines. By default MatchParen is enabled on all of my instances. Using gvim on my windows machine, it is doing exactly what I want - when my cursor is on a bracket, paren, etc. it visually highlights the match. It does not affect cursor navigation. However, on my Ubuntu boxes, when I move the cursor onto the character, it actually jumps to the match.
I'm sure that the behavior is caused by MatchParens because if I do a :NoMatchParen, it stops. Unfortunately, I also don't get the highlighting at that point. I can't figure out where my settings differ, though.
I'll like you even more if you can point me towards a plugin that will always highlight the closest enclosing pair of characters around my current position (like a code oriented version of MatchTagsAlways)
When showmatch is set, the cursor is actually jumping, and the following line fixes the problem:
set matchtime=0
More details:
http://vimdoc.sourceforge.net/htmldoc/options.html#'matchtime'
Just like FDinoff said in the accepted answer, this is probably only a problem of colors.
So if the color of the matching "paren" disorients you, tweaking colors of background and foreground is likely the solution.
But HOW do you do this?? ^^
I've had quite a journey through the vimdoc (it was not easy).
I've tested a whole bunch of variables and found that the relevant tweak is the [hi]ghlight command and specifically the MatchParen group.
The solution
Adding this in my .vimrc did the trick:
hi MatchParen ctermfg=208 ctermbg=bg
Note that vim config files are read from top to bottom, and some types of "words" are matched by several options. For example, a boolean could also be a keyword. Thus you have to pay attention to the order of these options.
How does this work?
My problem was that the background had the flashy color while the foreground had the color of the background of my terminal, which made it really confusing. Thus switching colors was the solution for me. But maybe you will have to tweak it differently.
First, you can check the current value for highlight MatchParen by entering the following command (while inside vim, in normal mode):
:hi MatchParen
You'll see hi MatchParen followed by XXX in the current style, followed by a list of argument=value separated by spaces.
The important arguments are ctermfg and ctermbg for the "terminal" vim, guifg and guibg for the "gui" vim. (Where fg means foreground and bg means background)
You can change a value and see the result in real time. Just put your cursor over a match character and enter the following command:
:hi MatchParen SomeArgument=SomeValue
This will not be saved, so don't worry. When you find a proper combination of values, you can add them in your .vimrc as shown above.
Personally, I set ctermfg to 208 (orange color) and ctermbg to bg (a keyword for the current background color, if known by vim).
If you use vim in a gui, take a look here for the available choice of colors.
The cursor isn't jumping. The color scheme probably has defined bad colors for the MatchParen highlight group which makes it look like the cursor is jumping.
Running default gVim (v7.4.461) without any configuration (i.e. no .vim files) in openSUSE 13.2 Legacy 32 Bit, :set showmatch? reveals that showmatch is on at start, which is not Vim's stated default behaviour. We can account for this by adding :set noshowmatch in our .vimrc.
I mostly use vim (console and gvim) full screen on a large monitor. My peripheral vision tends to miss details at the bottom of the screen.
Any suggestions on how to make the "search hit BOTTOM, continuing at TOP" message that appears when the current search wraps more obvious?
I do set
set noerrorbells
set novisualbell
in my vimrc to avoid the bell/screen flash every time I type Esc. However, re-enabling those options has no effect on search wrap (still no beep or flash on wrap).
Using visual bell to indicate search wrap would work well, I think. Any idea how to implement that?
It's hard to change that behavior, you'd have to override all built-in search commands (/, n / N, *, #, etc.) and any custom (plugin) mappings. If this is bothering you, maybe
:set nowrapscan
is worth a try. You can then still "manually" wrap via gg / G, which will soon go into your muscle memory, yet keep you alert.
My solution for now is to adjust my color scheme to make the WarningMsg color more obnoxious (in this case, bright red background). Here's the adjusted line from my color scheme file:
hi WarningMsg ctermfg=white ctermbg=red guifg=White guibg=Red gui=None
I find this makes the search wrap message much more noticeable.
I realize that this question has been posed before on this forum, but I didn't find an answer so here goes..
In Vim, is there a way to enable on-the-fly highlighting for all matches when searching?
If I enable incsearch and type "/something" it will highlight the first match only. If I enable hlsearch and type "/something", nothing happens until I press enter (it only highlights the previous search).
In emacs the first match will be highlighted, and (after a slight delay) all other matches on the screen are highlighted in a different color, giving almost instant feedback when scanning for matches in a piece of code.
use the n-search feature of easy-motion , it does exactly what you need(look in the gif demo)
BONUS: it also dims down the background for you that really makes searching easy
https://github.com/Lokaltog/vim-easymotion#n-character-search-motion
You can do this with the incsearch.vim plugin:
You need to first install the plugin and bind <Over>(incsearch-...).
You are looking for :set incsearch together with hlsearch. However all hits will have the same color.
I want to used different colorschemes for different filetypes and I added the following code in my .vimrc
function SetColorScheme ()
if &filetype != "vo_base"
colorscheme desertEx
endif
endfunction
au WinEnter * call SetColorScheme()
This works fine with one issue.
If I open a .otl file, say todo.otl (vo_base), and then open another file, say example.xml, using :sp the colorscheme desertEx does not get applied to the second window (the one having example.xml).
If I use BufEnter instead of WinEnter than desertEx gets applied to both the windows.
Is there a way to make sure that when I open a window with :sp the above function (a) runs, and (b) runs only for that particular window and not all the windows in the current session.
No there's no way to do that. There can be only one active colorscheme at the same time in vim.
Something that comes to mind is to create a color scheme that directly points to the low-level syntax groups in the Vim syntax files.
Take for instance c.vim for the C programming language. You will find for instance syntax hightlighting groups such as: cStatement, cLabel, cConditional, cType.. etc.
Take python.vim and you will find pythonDefStatement, pythonFunction, pythonConditional, etc..
So, if you want to use different color schemes for C code and python, you would copy the two original color schemes to ~/.vim/colors/mycolorscheme.vim and edit them to point to the low-level syntax groups instead of the generic high level groups such as Comment, Constant, Error, Identifier, etc. that are found in many available color schemes.
Note that you would probably want keep a default stanza of 'highlight' statements on top of these other two to take care of syntax highlighting for files that contain neither C nor python code.
To clarify, you could edit the celebrated 'Hello World' code and issue the following from the Vim command line:
:hi cInclude ctermfg=cyan guifg=cyan
You have not changed color schemes, other files displayed in other windows or tabs are unaffected, and yet the '#include' is now displayed in a different color.
Unless you absolutely need the feature, I would advise against it, because it pretty much breaks Vim's syntax highlighting. Besides, it will require significant work to convert the existing ':hi' statements comprised in the original color schemes because there are usually many low-level syntax highlighting groups.
A somewhat better approach might be to link the language-specific low level groups to high-level groups that are also specific to each language. This would help keep the custom color scheme file reasonably small, but requires additional inventory work.
Is it possible to not display a ~ for blank lines in Vim?
This confuses Mac Vim's scrollbar, and I quite don't like these tildes.
:hi NonText guifg=bg
That command should set the color of non text characters to be the same as the background color.
Vim 8.x:
You can now change the color just for the end of the buffer ~:
highlight EndOfBuffer ctermfg=black ctermbg=black
See changelog for Vim 8.x.
As jamessan said, you can’t disable them. The scrolling behavior isn’t specific to MacVim, either — it works the same way in the terminal and in gvim:
Instead of seeing this as a problem, what you should do is learn to see this as part of Vim’s flexibility. For example, you can use the zt command to scroll the current line to the top of the screen, regardless of where in the file it is. This can make it easier to write macros that do some work and then scroll back to where you were. The commands <C-E> and <C-Y> are made simpler because of this, as is the 'scrolloffset' option.
If you must, retrain your brain to think of Vim’s scrollbar as mapping to which line is on top, instead of which screenful is visible.
For NeoVim, you can set the fillchars value for eob to a space character and that will effectively hide it. (This might not work for plain Vim).
In Lua (Nvim 0.5+):
vim.wo.fillchars='eob: '
In VimScript:
set fillchars=eob:\
Note: Calling the above will override your fillchars value for other items as well (if set), so use this as a reference to set multiple values together:
set fillchars=eob:\ ,fold:\ ,vert:\│
Or use set fillchars+=... to append it your existing values.
You can't disable them, but you can change your colorscheme such that the NonText highlight group is colored the same as the Normal highlight group. However, this affects more than just the end of document tildes.
I doubt that it's actually "confusing" MacVim's scrollbar and if it is, then that's a bug in the patching that MacVim does.
The tilde ~ characters are meant to remind the user that those lines are not part of buffer content.
The above highlight trick will hide the ~ character, but it is still there. For some terminals, this may not even work. If you happen to be a Neovim user, you can use fillchars option to change the end of buffer symbol like this:
set fillchars=fold:\ ,vert:\│,eob:\ ,msgsep:‾
This will use space instead of ~ for end of buffer, effectively hiding the annoying ~.
You may also be interested in discussions here.