sindrets / diffview.nvim

Single tabpage interface for easily cycling through diffs for all modified files for any git rev.
Other
3.74k stars 105 forks source link

Highlights from `diff.vim` may not be loaded #351

Open drazil100 opened 1 year ago

drazil100 commented 1 year ago

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 :)

sindrets commented 1 year ago

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

:e $VIMRUNTIME/syntax/diff.vim
drazil100 commented 1 year ago

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.

sindrets commented 1 year ago

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.

drazil100 commented 1 year ago

It did. But the colors are different.

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

sindrets commented 1 year ago

Different than what?

drazil100 commented 1 year ago

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.

sindrets commented 1 year ago

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?

drazil100 commented 1 year ago

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.

sindrets commented 1 year ago

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).

drazil100 commented 1 year ago

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.

sindrets commented 1 year ago

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.

drazil100 commented 1 year ago

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