Fold colors suddenly change to difficult to read colors while scrolling buffer about neogit

[gegoune]

I don't think you should stress too much about what it looks like per colorscheme. There is absolutely no way you can support all colorschemes, as a matter of a fact it should be other way around - colorschemes should support your plugin and override default highlight groups it provides.

Come up with very neutral, non aggressive defaults and be done with it, I don't think any configuration flags should be provided here. If someone wants to disable specific highlighting they can do that by overriding it accordingly.

[RianFuro]

@TimUntersberger The problem is that we can't really do the right thing in this regard, someones color scheme will always look off with the provided colors.
I mean sure, we could add in a flag to only style the foreground if set, but then do we also add a flag to invert diff add/delete highlighting to better match colorschemes like onedark and nord? What about light themes where the provided highlighting would likely be too dark? I wonder where we would draw the line between providing configuration via flags and just letting the user override the highlight groups.

On that note, maybe we should also add overrides for the most popular color schemes to our repo? Or at least accept pull requests for that so other users don't have to worry about it. EDIT: scratch that, the after/colors directory sadly doesn't work as expected, so we can't easily extend colorschemes on our own anyway.

[RianFuro]

Huh, that would be the contextual highlighting not working well with your color scheme. It changes not because of the scrolling but your cursor moving into that region.
Basically, we have our own set of highlights for that since there's not really an equivalent in the defaults, so we just chose a set of greyscales.
You can check the readme on how to adapt those to your color scheme.

That being said, we probably should adapt the default highlighting to include fg colors, so it's at least readable.

[TimUntersberger]

@RianFuro it looks like the diff lines also have their color changed. I don't think this happens on my machine if I remember correctly.

[RianFuro]

@TimUntersberger We style the background since the expect the foreground to be highlighted red/green. With onedark the foreground is dark while the background is highlighted red/green. That's why the it looks off in his style, while it doesn't for me and you.

[RianFuro]

Alright, so I added some foreground colors to the highlights to make sure they are legible, no matter the user's colorscheme. I think that's as far as we can go on that matter, since we cannot possibly accommodate for all possible colorschemes out there; adaptions for that would need to go into the respective colorscheme plugin (even though I think we're not big enough to warrant that yet).

[Shatur]

@RianFuro, is there a way to disable this feature? It looks weird with my colorscheme too:
Without highlighting:

With highlighting:

[RianFuro]

@Shatur95 There isn't as of right now, but we really should have that option so I'll add that in.
That being said, you can just check the README.md for which highlighting groups we are using and override those to match your colorscheme. In my experience the context highlight really helps when staging unstaging, as it shows you exactly what you're affecting.

[TimUntersberger]

@RianFuro Tbh I dislike the new change too. If possible we should probably keep the old behaviour and have a flag for foreground colors.

[RianFuro]

@Shatur95 just pushed an update, you can now set disable_context_highlighting = true in your setup call to completely disable context highlighting

[Shatur]

@RianFuro, thank you!

[Shatur]

@RianFuro, What if use CursorLine for it by default? Should looks awesome for any theme.