Colour choices for highlighting blame hashes?

[volo1st]

The new feature introduced in 785bb15 is very useful, thanks a lot.

However, there are several issues:

• colors are not in 24 bits, since we have termguicolors set, should we use the wider color spectrum?
• colors look too different compared to the editor color scheme, should we pick colors from the currently selected color scheme?
• colors are randomly picked so the readability of some hashes is not that good because of bad contrast, see the dark purple part in the screenshot below.

Is it possible to improvement those a bit, or even add some customization options?
Many thanks!

[tpope]

1. I don't know why it would be failing to use 24 bit colors unless you also have CSApprox installed, and even then, guifg should take precedence over ctermfg, no?
2. There's only 7 major color groups in your typical color scheme. That's not nearly enough for this feature to be useful.
3. Personally it's rare that I actually need to read the hash, and I would happily accept the occasional need to squint over a narrower gamut. I suppose one could explore tweaking the colors with respect to 'background'.

[volo1st]

1. You are correct, the vivid colors randomly selected in the screenshot gave me a wrong assumption of they are not using 24-bit colors, but actually, they are.
2. I see. I was thinking about we just need to make sure that the adjacent hashes have different colors if the values are different, but suddenly realized that if you have more than 7 different commits for that file (which is very likely) then some colors will be used more than once, which is even more confusing.
3. I don't read the hash that much neither, I use to hit * or # to highlight and jump to all the hashes with the same value. For the lack of contrast part, today I even observed a hash been colored in a very dark blue #0F2237 against a dark background #1D2021 which is indistinguishable to my eyes. I'll see if I can contribute on this.

[unphased]

Hi, I chose to comment in this issue because my suggestion is very related to this topic.

I want the colors to be (yes, 24-bit... but more importantly...) a heatmap based on recency. It doesn't have to be super accurate and modulated with actual time durations, but if I can tell at a glance that the warmest colors are the most recently changed lines, that would make the blame view quite a bit more awesome!

Even if it was a fixed palette of ROYGBIV or something, assigning semantics to the colors in addition to using them to discriminate the commits would be great.

Failing this, another column shown as some form of bar-chart-like-indicator of time since changed (or heck even just a "x days/months ago" column) would also work. Just anything that is a step beyond the raw timestamp. (Not to say that the raw timestamp shouldnt be presented. it should be!)

At any rate. Yeah, if we're going to keep the actual blame text content and just add colors, then yeah, the idea is just that colors can visually represent an axis too!

[tpope]

I actually tried to implement a heatmap for the timestamp field but no matter how I tuned it, most files ended up using a very very small sliver of the spectrum. See the (very old) blame_colors branch.

[vitaly-zdanevich]

So, no plans to use non-random colors?

[tpope]

If you can dig in on how Github picks what colors it uses, that might help solve the "small sliver of the spectrum" problem.

But note my original plan was to highlight the timestamp field differently, not to replace the random colors. The random colors are awesome imo.

[jkopano]

In cases like these, not so
It's barely visible

[jez]

I actually tried to implement a heatmap for the timestamp field but no matter how I tuned it, most files ended up using a very very small sliver of the spectrum. See the (very old) blame_colors branch.

For posterity: the branch was called blame_color (no s), here's a compare link:

https://github.com/tpope/vim-fugitive/compare/blame_color

[zaakiy]

Oh wow @tpope, I've dealt with this color issue before! The reason that a lot of colors look the same is because of the bias of the human eye. So, we have to compensate for that bias in code by only selecting certain ranges.

As it turns out, RGB (and therefore HEX) is quite biased in the way that it represents color, but HSL is actually very good because it gives us a good spread.

I remember as a kid we could adjust the Red, Green, and Blue separately on our CRT televisions, because sometimes the one or the other color would degrade. So RGB is great for analog, but terrible for the digital world at controlling and representing color, which is why Adobe came up with their own version of RGB.

Here's my recommendation with HSL:

1. Only change the background color. The foreground color won't be detectable but you probably found this out already as part of your journey.
2. Hue, I would say to stick with HSL hue of between 0 and 300, or alternatively 60 and 300.
3. Saturation should by about 80% which is fairly balanced, or 100% if you want to go for a more bolder appearance.
4. Lightness, start with 50% for nice bright color (maybe for the most recent), and then fade away towards 80% (maybe for the oldest)....or you can go in the opposite direction for a darker look (e.g., for light themes).
5. The choice of black or white text for a colored background depends on the background’s lightness, with black text typically used on lighter colors and white on darker ones. However, the threshold for switching between black and white varies by hue, as different colors can appear lighter or darker to the eye even at similar lightness levels, requiring adjustments for optimal contrast. It can take a few minutes of experiment. If you want to be lazy for the first iteration, you can just select a lightness range that works for all-white or all-black text. Or even lazier, don't use foregound text.

I would suggest that you use the hue to control the color of code say, for the last 4 weeks, because that's represents the strongest differentiator to the eye.

And then lightness to fade away the color of anything older than 2 weeks. Notice that there is a deliberate overlap, for aesthetic purposes. I think you're a better judge of the actual age and the actual overlap, but at least I've given you something to start with.