If git is performing a 3-way merge and has a conflict it can't resolve, it marks up that area of the file like this:

No unresolvable conflicts here
<<<<<<< HEAD
||||||| parent of ...
>>>>>>> ...

Is there a way (and, if so, how) to change the background color of these 3 "sections":

  • <<<<<<< HEAD through the line before ||||||| parent of ...
  • ||||||| parent of ... through the line before =======
  • The line after ======= through the line >>>>>>> ...

(EDIT: The question revolves around if there's a way to highlight certain lines depending on other lines. xyz would ordinarily not be highlighted, but since it's between <<<<<<< and ||||||| it would be highlighted.)

With also being able to handle other sets of conflict markers?

Using the most recent version of vim available at the time of a comment. So, as of now, 8.1.1183.

I use a black background and 256 colors in my terminal. I was thinking it would be nice to give these sections using the darkest R/G/B/C/M/Y colors, so they didn't cause much of a problem with syntax highlighting. (Talking about ANSI colors 52, 22, 17, 23, 53, and 58 - not the 1-6 colors.)

  • A simple google search query would have sufficed: github.com/rhysd/conflict-marker.vim – klaus Apr 18 '19 at 2:48
  • @klaus, I should have mentioned I looked at that plugin while doing a lot of google searching. That plugin highlights the conflict markers themselves. It doesn't also highlight the text those markers are associated with, on other lines. I think the big issue at hand is if there's a way to highlight certain lines depending on other lines. Meaning, in my example, xyz would ordinarily not be highlighted, but since it's between <<<<<<< and ||||||| I would like it highlighted. – user1902689 Apr 18 '19 at 19:57

In your Vim config, you can do the following (change the colors and styling to your liking):

function! ConflictsHighlight() abort
    syn region conflictStart start=/^<<<<<<< .*$/ end=/^\ze\(=======$\||||||||\)/
    syn region conflictMiddle start=/^||||||| .*$/ end=/^\ze=======$/
    syn region conflictEnd start=/^\(=======$\||||||| |\)/ end=/^>>>>>>> .*$/

    highlight conflictStart ctermbg=red ctermfg=black
    highlight conflictMiddle ctermbg=blue ctermfg=black
    highlight conflictEnd ctermbg=green cterm=bold ctermfg=black

augroup MyColors
    autocmd BufEnter * call ConflictsHighlight()
augroup END

Which renders as follow:

enter image description here

Is it what you are after?

| improve this answer | |
  • That's absolutely what I'm after. I'm having some oddities with the vimscript though. If I type your example in, it looks just like the image you posted. If I save your example then restart vim editing the new file, it gets horribly out of whack. (vim 8.1.1186.) Even weirder, if I then delete all lines in an existing file showing weirdly, and re-paste its content, it's still showing wrong. i.ibb.co/jvGMH6t/wtfvim.jpg – user1902689 May 9 '19 at 3:39
  • Using it in an actual merge scenario triggers an even weirder coloring than the image I linked, with: conflictStart being properly highlighted; the ||||||| part of conflictMiddle in red but the rest of the line in blue as it should be; the ======= in red; the >>>>>>> .* line in yellow (where did yellow come into this, there is no yellow); and the rest of the file which shouldn't be part of the conflict at all in green, still being picked up as conflictEnd according to the SynStack() function from stackoverflow.com/questions/30247603 – user1902689 May 9 '19 at 3:49
  • Likewise, using the actual merge scenario, if I copy/paste the contents to a new file, it is displayed as expected, but as soon as it's saved and vim is restarted, it displays wrong. – user1902689 May 9 '19 at 3:50
  • In an actual merge scenario, you can disable the original diff coloration using :diffoff, leaving only the filetype's syntax highlight. I will play a bit to see for your first case. – padawin May 9 '19 at 7:45
  • Ack, sorry, had forgotten I had left the conflict_marker plugin installed after trying it before my post, which was conflicting and causing the problem. Removing that and no longer having that problem. – user1902689 May 9 '19 at 7:47
| improve this answer | |

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.