It's possible for multiple highlights to affect the same areas in the buffer and work correctly. For example syntax-related colors usually affect fg (foreground, text glyph) color, diagnostic style highlights apply stuff like curled underlines that apply guisp (color that applies for underlines), and there are more properties that we can independently applied to the same text without conflicting such as italic, bold, and bg color.

However, for visual reasons, there are situations when I would want bgcolors conflicting and control which to take precedence. The question is when I have multiple plugins is there a global priority mechanism I can use to force certain highlight groups to "trump" others when they conflict?

The current example:

GitSigns plugin applies word-diff highlights for added and changed zones within the buffer (highlight group GitSignsAddInline). I am having trouble convincing another highlight group (highlight group YankyPut) to take precedence over it. YankyPut is ephemeral and disappears after a timeout.

As I understand it, the way it works is that maybe the last-defined highlight group takes precedence? It can be kind of hard to test actually. Let's suppose that is the case. Then if in this example GitSigns for whatever reason has to legitimately re-set its groups on a regular basis then that makes it nearly impossible for me to ensure that the Yanky highlight group is then defined afterwards. It would not be sensible to introduce some sort of communication dependency across these unrelated plugins.

Please do not offer "change YankyPut to use underline" as a solution. That will certainly work, that's not what I'm interested in. I just want to understand how I can gain more precise control over conflicting higroups set on the same areas of the buffer.

1 Answer 1


There is no explicit way to control how two highlight groups interact with each other.

The only hack at our disposal (and I insist, it is a hack) is the use of reverse, which effectively gives the highlight group some kind of priority. But it is far from perfect as it can lead to some undesirable bleed-through issues.

Vim has some internal logic for combining attributes but it is just that, internal, and there is no user-accessible way to affect the way it works. And it doesn't have any internal logic for adjusting priority to begin with, so there is no user-accessible way to explicitly affect priority.

This thread might be of interest.

Note that the semi-recent :help hlset()/:help hlget() don't provide much help because, well, the plumbing for what you and all colorscheme authors want is simply missing.

  • Yeah for now I have found that highlights seem to work perfectly properly together in overlapping ranges as long as the attributes being applied aren't conflicting with each other. For example I eventually got a bit tired of stuff like the highlighting of the word under the cursor interacting with background colorized zones, leading to strange/confusing looking stuff. So I decided to make the word-under-cursor highlight only set gui=bold and bold keeps it still visible enough (I can step it up to also make it apply an underline) while now no longer conflicting with bgcolors.
    – Steven Lu
    Commented Mar 19, 2023 at 1:14
  • I still really think the highlight system could do with a priority attribute and that'll handle this issue without introducing backward-compatibility concerns or break anything. But maybe I'm still missing something more nuanced that would make that difficult.
    – Steven Lu
    Commented Mar 19, 2023 at 1:16
  • We, colorscheme authors, all share that opinion. All it needs is a PR, really.
    – romainl
    Commented Mar 19, 2023 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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