7

I've set the background color of the current line to light gray like this:

hi CursorLine cterm=NONE ctermbg=253

(Note that my color scheme is black-on-white.)

However, this way any background colors set by syntax highlighting is overridden by this, i.e. if a word on the current line is highlighted, say, white-on-red, I see the text as white-on-light gray. I only see that the line (or part of it) is supposed to be highlighted red if I move the cursor to another line.

What I'd like is that only the part of the current line for which no special background color is set is highlighted light-gray by cursorline, but that the cursorline highlighting is overridden by syntax highlighting.

Is this possible?

PS: The specific case where I've encountered this issue is the second line in a git commit tmp-file, where the text on the second line is white-on-red (for whatever reason).

|improve this question
  • The "whatever" reason is that you are supposed to leave the second line of your git commit blank. That is the preferred style with git commits: 1 short line (~60 characters) describing the commit, followed by a blank line, followed by an explanation as large as you want/can. – Shahbaz May 15 '15 at 11:34
  • @Shahbaz: Ok thanks for the explanation, that clears things up. I've only used git casually for some private stuff so far but have never actually learned it (i.e. read a guide or so), so I'm not yet aware of such things. Reading the git book is on my TODO list, though, before starting to use git more extensively. – flotzilla May 15 '15 at 11:52
  • Git is awesome and can do things beyond your imagination, yet is very simple for everyday use. Happy learning! – Shahbaz May 15 '15 at 12:21
5

I had once suggested a change on the vim_dev mailing list, but Bram was against it, with the following reasoning:

Having the syntax background color overrule the 'cursorline' background color will result in the cursorline to be broken in pieces or hardly viewable.

Alternative

With the matchadd() function, you can specify a {priority} that determines whether the highlighting will be in front of or behind the cursorline. Unfortunately, this is totally different from syntax highlighting, and even scoped differently. Therefore, it doesn't help with syntax issues, but enables other uses, e.g. highlightings by my Mark plugin.

Workaround

You can keep the syntax background color if you use the reverse attribute. For instance, instead of defining

:hi Todo guifg=Black guibg=Yellow

do this:

:hi Todo guifg=Yellow guibg=Black gui=reverse

Unfortunately, now you have another problem: The text (foreground) color changes from black to the cursorline color. This works well for the white-on-red error highlighting you mention (turning to (bright)-cursorline-on-red), but less well for my Todo example (cursorline-on-Yellow). Additionally, the reverse attribute is not supported in all terminals.

Summary

Unfortunately, there's no easy fix. Despite the shortcomings, I use the above workaround (kudos to @romainl, in whose config I first saw this!)

|improve this answer
  • Thanks for your answer. But do I understand it correctly that your suggested solutions/workarounds are to change the syntax files (i.e. to specify that a specific highlighting should have precedence to the colorline highlighting)? If so, that's not what I'm looking for, what I'd like to specify is for the colorline highlighting to be placed behind any syntax highlighting. In that case, I'll just have to accept the way it works, i.e. that syntax highlighting is always overridden by the colorline highlighting. – flotzilla May 15 '15 at 12:22
  • Syntax files usually don't define colors, they just :hi link to existing groups (like Todo). My workaround would have you change your personal colorscheme, either directly or in your .vimrc. – Ingo Karkat May 15 '15 at 12:57
  • Ok yes sure, at second thought that's more or less what I meant. Still, I'd have to change the behaviour of specific highlightings in order to override that of cursorline, rather than changing the behaviour of cursorline to be overridden by any highlightings (which apparently isn't possible). So for now I'll just (have to) accept fate, but your workaround might come in handy if there are a few specific highlightings that often annoy me, and which I could then fix selectively. – flotzilla May 15 '15 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.