2

After updating to vim 9.1 yesterday, diff highlighting colors were broken for me. Comparing with an older vim (7.4) on a different machine, it seems that the cause was probably a change in the diff.vim syntax file using DiffAdd/Delete/Change as the relevant highlighting groups instead of Identifier/Special/PreProc like previously; thus I fixed this by adding the appropriate hi entries to my color scheme. But during the investigation, I could not figure out how the default colors for those hl groups are determined.

For example, here are the values for DiffDelete as given by :echo hlget('DiffDelete') before adding a hi DiffDelete entry to my scheme:

[{'id': 30, 'ctermfg': '12', 'name': 'DiffDelete', 'gui': {'bold': v:true},
'term': {'bold': v:true}, 'ctermbg': '6', 'guibg': 'DarkCyan', 'guifg': 'Blue'}]

Also, vim used the guifg/bg values instead of the ctermfg/bg values, as ctermfg=12 should be red but deleted lines were highlighted blue on cyan.

Example:

example.

I checked the following places for highlighting definitions and related config:

  • The default color scheme under $VIMRUNTIME/colors/default.vim is basically empty and does not define any relevant colors.
  • My existing color scheme (based on mustang) did not define them either.
  • Other color schemes in $VIMRUNTIME/colors definie DiffDelete highlights, but no scheme matches even one of the fg/bg values.

I'm setting t_Co=256 in my vimrc and $TERM is xterm-256color; I don't think any other vimrc settings are relevant.

So in summary, here's my questions:

  • Are the default color values such as the hlget output above hardcoded somewhere in the vim code? If not, is it in some configuration file outside of $VIMRUNTIME, or is it dynamically determined based on the env / terminal / whatever?
  • Why does the default highlighting above result in the guibg/fg being applied instead of the ctermbg/fg values - shouldn't the gui values only be used in gvim etc and not in a terminal?
8
  • What version did you have prior? Can you try building that (or checking it out) and comparing?
    – D. Ben Knoble
    Commented Jan 4 at 14:34
  • 1
    fyi: I documented it here: github.com/vim/vim/commit/… Commented Jan 4 at 15:18
  • @D.BenKnoble I'm on arch linux and had vim-9.0.2167 previously. Highlighting looks as expected when reverting to that version and removing the hi Diff* lines in my colorscheme. The hlget('DiffDelete') output is identical, but it's not yet relevant in that version as can be seen in the doc linked by Christian.
    – l4mpi
    Commented Jan 4 at 15:24
  • @ChristianBrabandt thanks, that explains that my analysis of the cause was correct. However, it does not explain what causes the wonky default highlighting for those hl groups.
    – l4mpi
    Commented Jan 4 at 15:25
  • @romainl I added an example image
    – l4mpi
    Commented Jan 4 at 15:34

2 Answers 2

2

Are the default color values such as the hlget output above hardcoded somewhere in the vim code?

Yes, the defaults are hardcoded in C source. Except, named color constants are defined in VimScript runtime (in late builds). That would be a shame if Vim crashed on startup if one had erased VIMRUNTIME folder, wouldn't it?

Why does the default highlighting above result in the guibg/fg being applied instead of the ctermbg/fg values

This depends on :h 'termguicolors' option setting. It is off by default, so blame your config. However, many popular color schemes do not provide any reasonable values for 256 color palette, and almost all terminal programs have support for TrueColor anyway. So everyone types set termguicolors into personal vimrc, and only few bother about its meaning.

8
  • set termguicolors? shows notermguicolors, so apparently it's off in my config, and turning it on changes lots of colors. So I think it has to be something else. The only related setting in my rather minimal .vimrc is t_Co=256 and potentially nocompatible (not sure if it does anything here but :h termguicolors mentions "This option is reset when 'compatible' is set").
    – l4mpi
    Commented Jan 5 at 9:39
  • @l4mpi Don't set t_Co manually, as it's set from TERM. And never touch compatible option for any version built in the current millenium. termguicolors is the only option that forces terminal vim into 24-bit color mode. If you claim otherwise then you are just wrong.
    – Matt
    Commented Jan 5 at 11:59
  • I'm not claiming anything about 24 bit modes. I'm just stating a fact; my vimrc results in notermguicolors (and I just confirmed that it has no relevant settings by removing everything but syntax on and colorscheme $name - same behaviour). You are the one claiming that the guifg/bg is applied due to termguicolors and I'm saying that is not the issue in my case as it's not set. Maybe I'm missing something else entirely, but to my understanding the default ctermfg/bg values for DiffDelete should result in red on yellow, and as you can see in my screenshot I get blue on cyan instead.
    – l4mpi
    Commented Jan 5 at 12:21
  • @l4mpi You are one who wrote in your question literally "vim used the guifg/bg values instead of the ctermfg/bg values". And guifg/bg are 24-bit long. Now you say you didn't say anything about 24-bit... So don't be surprised if you are not understood.
    – Matt
    Commented Jan 5 at 18:12
  • That is how I interpreted the visuals I get (as shown in the screenshot) in combination with the hlget('DiffDelete') output. I apologize if that was incorrect and caused confision, however how else would you interpret that data?
    – l4mpi
    Commented Jan 8 at 8:27
1

FWIW, here is the content of a diff file without the change mentioned by Christian in the comments:

before

Obviously, the exact colors depend on the colorscheme, but it certainly is meaningful and readable.

Now, here is how the same file looks after the change in question:

after

This is way too noisy.

1

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.