Gblame timestamp coloring and support for 256 color terminals

[bhaak]

I've been using your "blame_color" branch for a long time and found it tremendously useful for finding recently changed lines. The visual cue due grayscale based on age helps a lot there.

While updating it to the current HEAD, I also added support for coloring hashes and timestamps in a 256 color terminal.

I've been using this patched version for several months now and haven't encountered any issues.

[tpope]

I never merged this because I was extremely unsatisfied with the color distribution. Six of the 16 colors will only be used if you have code that is older than software itself. You can multiply by a factor to use more of the scale, but go to far and even year old code starts to look washed out. I don't think a logarithm is the solution to this problem.

In the intervening years since I first prototyped this feature, Git has gained the blame.coloring=highlightRecent option, which adds one color for code less than a month old, and one color for code less than a year old. That seems way more useful than what we're doing. Maybe we should switch to a system like this? We could do more than 2 colors, but less than 16.

As for your 256 color terminal additions, that is what the calls to CSApprox are for. That plugin abstracts away a lot of differences between how various terminals implement color support, but I think most of those differences are moot now, so we can probably replace CSApprox entirely with changes like yours. But a couple of notes:

• For dates, you're going from dark gray to white rather than black to white, which is completely arbitrary because those colors are flipped around based on the 'background' option. (And keep in mind with the current scaling, half the colors are basically never used.) CSApprox computed [16, 233, 235, 236, 238, 240, 241, 243, 102, 246, 248, 250, 252, 253, 255, 231] which seems like as good of choice as any.
• For commits, you're doing a dance to avoid black. Instead of % 215, you should scale these with * 215 / 255 (or whatever the appropriate scale is) so the colors merely shift a bit rather than jump all over the place when switching between terminal and GUI.

[tpope]

Ignore that final bullet point for now, I was forgetting some of the details involved.

[bhaak]

Six of the 16 colors will only be used if you have code that is older than software itself. You can multiply by a factor to use more of the scale, but go to far and even year old code starts to look washed out. I don't think a logarithm is the solution to this problem.

In the intervening years since I first prototyped this feature, Git has gained the blame.coloring=highlightRecent option, which adds one color for code less than a month old, and one color for code less than a year old. That seems way more useful than what we're doing. Maybe we should switch to a system like this? We could do more than 2 colors, but less than 16.

I've been using the Gitblame feature regularly on two repositories, of which one is 10 years old and another that is almost 40 years old but both getting almost daily updates. I've been mainly interested in seeing recent commits stand out well when using Gitblame as that's also where most of the bugs will appear. For older commits I don't think the timestamp coloring is that important (hash coloring gets more valuable in such a case).

The defaults of blame.coloring=highlightRecent are not fine grained enough for my taste. If I would have configure it (but I don't, because I have this patch :) , I would probably set it to 1 day, 2 days, 3 days, 1 week, 2 weeks, 1 month, 3 month, 6 month, 1 years.

As for your 256 color terminal additions, that is what the calls to CSApprox are for.

The problem with CSApprox is that it isn't installed by default and quite obscure. It's also not mentioned in the vim-fugitive documentation. I only learned about it from reading the source. When I first looked for it, I only found the version at vim.org/scripts which I didn't get to work. I only recently learned about the "godlygeek/csapprox" repository that allows to bundle it like any other plugin.

But in any case, nowadays almost every terminal supports 256 color mode out of the box, supporting it directly will just work for most people (88 color mode can be ignored and those that still have only 8/16 colors are out of luck anyway).

For dates, you're going from dark gray to white rather than black to white, which is completely arbitrary because those colors are flipped around based on the 'background' option. (And keep in mind with the current scaling, half the colors are basically never used.) CSApprox computed [16, 233, 235, 236, 238, 240, 241, 243, 102, 246, 248, 250, 252, 253, 255, 231] which seems like as good of choice as any.

I tried to make the grayscale values in shade256 evenly distributed so it can easily used for both background=dark and background=light. But for background=dark, I guess it's more likely that the actual background color is black than the background color is white for background=light. That's why I was avoiding the color black there. But I'm not a light background user, I might be wrong with this reasoning.

Ideally I would want to have a dynamic calculated list of colors that go from foreground color to alnist background color. But that goes beyond my current abilities in vimscript and I don't even know if this information is exported in a suitable way.