I recently had to re-install my OS: after updating everything, I noticed some colorscheme changes in Neovim. The colorscheme didn't change, but the way some groups are colored did. I was searching for it online and found issue #26378.

In my particular case the problem was with the colors that were previously specified by Identifier color group (which are now rendered as a Normal color) and I think the mentioned github issue addresses that change:

@variable and @lsp.type.variable are cleared instead of linking to Identifier to reduce visual noise.

At least, I think this is a cause of my problem; I certainly might be wrong.

What I didn't find though, is a way to revert to the old behavior (if that's even possible).

I tried setting @variable to the same color the Identifier is set to, but nothing has changed. Also, changing the Normal color to Identifier's color does work, but I don't want the rest of the text that used to be Normal to have the same color as Identifier, if that makes sense.

What highlighting looked like before

What highlighting looks like now

The first image is how things looked before the update while editing shell scripts, and the part I'm referring to is from lines 18 to 15 to be precise (relative numbering). On that image you can see most of the text is purple, while the same portion on the second one is mostly white (Normal), except for actual variable names (var and var_name)

The purple color is the color of Identifier color group, but even though I'd consider local overwrite_color prompt as identifiers, they are not colored the same anymore. Again, I found this GitHub issue where they explicitly say they broke a link related to Identifier. I'm not sure if that's what causes the problems I see though.

  • Welcome to Vim! It would be helpful to have a concrete example such that the problem could be reproduced such that the proposed solution could be tested before delivery ;-) Would that be possible for you? Commented Jun 22 at 17:56
  • @VivianDeSmedt Sure, what kind of example would you need? :) I can post screenshots from before and the one from now, if that helps :)
    – s0la
    Commented Jun 23 at 12:12
  • What we would need is a small text that illustrate your problem. The filetype of your buffer and the special area of the text where you want to understand or change the behavior. The idea is to ease the reproduction of your problem such that we can verify before we publish a solution that it is working at least for us ;-) Commented Jun 23 at 12:28
  • See also vi.stackexchange.com/q/44887/10604
    – D. Ben Knoble
    Commented Jun 23 at 18:58
  • @D.BenKnoble Thanks for that reference, though my colors are already set to gui, so there's nothing to change.. Running set notermguicolors in command mode totally messes things up, and adding it to init.vim doesn't do anything at all.. Mind you, I don't have such severe differences as the other user reported, in my case it's specifically just those couple instances that used to be colored as Identifiers..
    – s0la
    Commented Jun 23 at 23:27

1 Answer 1


You might just be looking for

augroup fix_colors
  autocmd ColorScheme * highlight! link @variable Identifier
  autocmd ColorScheme * highlight! link @lsp.type.variable Identifier
augroup end
  • Hey Ben, thanks again for trying to help! As I said in the post, I actually tried to explicitly define @variable to the same color Identifier is set to, but that didn't have any effect.. After waiting a couple of days since I opened this question, I also posted an issue on gh yesterday, and someone suggested opening a lua file and re-defining all the colors linked to Identifier, which I didn't and it still doesn't work..
    – s0la
    Commented Jun 25 at 19:27
  • Btw, I didn't post this (neither mentioned in the original post nor posted the image), but my fzf floating window for searching files also has a black margins, I posted that on the github issue though.. I'm not sure what's going on..
    – s0la
    Commented Jun 25 at 19:29

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.