Gblame timestamp coloring and support for 256 color terminals #1654
Conversation
This code is taken from tpope's "Timestamp WIP" branch and updated to the current HEAD.
Using only colors from the 6x6x6 cube without system colors and the grayscale ramp at the end of the 256 color mode. Those colors also have the nice property of not being too dark or too bright and therefore not making the hash unreadable on a dark or light background.
bhaak
changed the title
|
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 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:
|
|
Ignore that final bullet point for now, I was forgetting some of the details involved. |
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.
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).
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. |
|
This is one of the two places that mention the coloring of git blame. |
|
I've played a little bit with the colouring algorithm on my branch: https://github.com/shadowwa/vim-fugitive/tree/commit-date-playground simple log without adapting for oldest commit date (same as blame_color branch)complete day to ln
Going back to -22305 is overkill, I'm quite sure mesolithic guys weren't using git, but I'm not an historian and could be wrong. complete minutes to ln
Using minutes as step for log calculation is better for the range but still getting 6 or 7 different colours in the blame window. with factors to get step at 1 day, 2 days, 3 days, 1 week, 2 weeks, 1 month, 3 month, 6 month, 1 year
trying to calculate factor to match the steps @bhaak gave in this thread show almost the same number of colours. log adapting for oldest commit dateI've then decide to adjust the factors to take into consideration the newest and latest commit appearing on the file blame and adjust the logarithm to match theses. In theses table the steps get for a file blame with commit from now to ten years ago.
Here the scale is OK for the oldest commit but I don't really care to have a difference between commit happened 1, 3 or 14 seconds ago. To my biggest disappoint, I only got 1 or 2 colours more than the previous tests. and the same happen if I try to match with hours or days.
Linear adapting for oldest commit dateI also tried a linear approach and if using all 16 colours palette, I lose the focus on the most recent commit, but I find it quite useable.
Quadratic adapting for oldest commit dateTrying to get a little more focus on the more recent commit, I switch to a quadratic curve and it's the one that gave me the more satisfaction on my projects.
Adjusting to match newest and oldest commit allowed to be able to uses almost all the colours. You can try the different scale from my branch by (un)commenting lines in https://github.com/shadowwa/vim-fugitive/blob/2c7234761ffc7d734698cec90e153f725bf17f08/autoload/fugitive.vim#L7387-L7395 |
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.