diffview.nvim icon indicating copy to clipboard operation
diffview.nvim copied to clipboard

Highlights from `diff.vim` may not be loaded

Open drazil100 opened this issue 2 years ago • 12 comments

No configuration Screenshot from 2023-04-28 03-51-28

With configuration provided in readme or loading a colorscheme after the fact Screenshot from 2023-04-28 03-51-46

The bright side is my custom colorscheme now has diffview support :)

drazil100 avatar Apr 28 '23 09:04 drazil100

diffAdded and friends are not set by us. It's set by the builtin diff syntax plugin:

:e $VIMRUNTIME/syntax/diff.vim

sindrets avatar Apr 28 '23 11:04 sindrets

So it is. Changing colorscheme breaks in vim too it seems. I just assumed they were part of the plugin.

That said there is still the issue of require('diffview').setup() clearing these highlight while at the same time relying on them.

drazil100 avatar Apr 28 '23 11:04 drazil100

No, this plugin doesn't clear any hl groups. I think what you're seeing is that you're opening a diffview before the builtin diff syntax has ever been loaded. It only loads when setting the diff filetype. This is something I never considered, as most color schemes set these highlights explicitly (even the builtin ones. Just not the default one).

You can confirm this by running this command before opening a diffview:

:enew | setl ft=diff

This should load the diff syntax and set up the hl groups.

sindrets avatar Apr 28 '23 12:04 sindrets

It did. But the colors are different.

Screenshot from 2023-04-28 07-06-40

drazil100 avatar Apr 28 '23 12:04 drazil100

Different than what?

sindrets avatar Apr 28 '23 12:04 sindrets

Than the first image. The added and removed number colors are different. The default ones that were generated had the correct colors (green for added and red for removed) but this command gave me yellow for added and purple for removed. Idk why it did that but it's more right than when these highlights were cleared and more wrong than where I started.

drazil100 avatar Apr 28 '23 12:04 drazil100

The first image uses custom highlights. These are not the default highlights set from diff.vim:

image

but it's more right than when these highlights were cleared and more wrong than where I started.

Okay? Then why don't you just use the highlights from the first image?

sindrets avatar Apr 28 '23 12:04 sindrets

Also I should clarify. I tested thoroughly with and without the require setup call. I could load a diffview immediately after launch and 100% of the time I would get the first image and then with the require setup 100% of the time I would get the second.

I definitely did not specify these colors in my color scheme before tonight. Now I am thinking the only reason diffview is "breaking" these colors is because they were broken to begin with and some other plugin was responsible for attempting to fix them.

drazil100 avatar Apr 28 '23 12:04 drazil100

I don't know what mean by the highlights being "broken". There's nothing broken about these highlights. They are either set or not. You have brought my attention to the fact that we should probably ensure that diff.vim has been loaded.

Now I am thinking the only reason diffview is "breaking" these colors is because they were broken to begin with and some other plugin was responsible for attempting to fix them.

Diffview is not doing anything with these highlights. We don't set them and we don't clear them. We only link to them. Again, I have no idea what you mean by "attempting to fix them". I don't understand in what way you perceive them to be broken.

If you didn't set these highlights, something else in your runtime did (syntax, filetype, or some other plugin).

sindrets avatar Apr 28 '23 12:04 sindrets

I don't know what mean by the highlights being "broken". There's nothing broken about these highlights. They are either set or not. You have brought my attention to the fact that we should probably ensure that diff.vim has been loaded.

Broken was in quotes cause I couldn't think of a better way to phrase "thing that I didn't want to happen happening". I don't actually think it's broken.

Again, I have no idea what you mean by "attempting to fix them".

I meant some other plugin noticed these highlights were not loaded and rather than loading diff.vim they used another method to assign these highlights. After a quick look I found that gitgutter is what was setting these colors for me.

I am sorry if I miscommunicated anything. I am not here trying to start drama or anything. All I wanted was to provide useful feedback to your amazing plugin.

drazil100 avatar Apr 28 '23 13:04 drazil100

No worries, I didn't take it as such. Apologies if I came across as defensive. I was merely using concise language for the sake of clarity.

Your issue did lead us to discover a potential issue with the default hl links we're using. I'll see if I can look into fixing it soon.

With regards to your color scheme, the rational conclusion seems to be that you should set the diff* highlights explicitly (if you haven't done that already) unless you want the default links that are set in diff.vim.

sindrets avatar Apr 28 '23 13:04 sindrets

I fixed it long before I posted this issue. I actually had to revert my fixes to grab the screenshots for this issue. xD

I still don't know what it is about require('diffview').setup() that triggered my setup to clear those highlights. I believe you when you say you don't do anything to the highlights but the programmer in me now wants to learn what weird vim/nvim feature they decided to put this obscure secondary effect of clearing highlights into. xD

drazil100 avatar Apr 28 '23 14:04 drazil100