🐛 Custom git log coloring is overwritten

[0xC0FFEE]

When specifying a custom git log format which includes colors (e.g. via git log --patch --pretty=format:'%C(red)I SHOULD BE RED') delta overwrites these custom colors starting from the seconds log message.

[dandavison]

Hi @0xC0FFEE, thanks for this. I'd like to support this, but it might require a bit of thought/effort. Any thoughts/ideas are welcome!

From the beginning, delta has immediately stripped out all ANSI escape sequences as soon as it receives a line of input. I think I was thinking that it would be difficult to parse the input correctly with them present.

We have requests #72 and #144 for --color-moved support, which is another example of something which is only communicated by git via ANSI escape sequences (AIUI). I.e. in contrast to added and removed lines which git communicates with +/- line-beginning markers, as well as ANSI color escape sequences.

Perhaps there could be a solution where delta continues to strip them out, and then reapplies them before emitting the line.

[0xC0FFEE]

Hi @dandavison, what do you think about storing the original lines as well? The parsing could be done on the stripped line and if delta wants to output the original line it can do so at any point in time.

AFAICT --color-moved is similar but different. In order to support it, delta needs to know (e.g. via configuration or by reading .gitconfig) which color moved lines will be printed in. Then delta can detect these lines and change the format accordingly. Custom log formats on the other hand can be as complicated as you can think of. I doubt that parsing out all escape sequences and reapplying them is worth the trouble. So I guess the default case (i.e. when delta does not apply custom coloring/formatting) could be to print the original line with all escape sequences?

[dandavison]

Thanks for those thoughts @0xC0FFEE. I've done exactly as you suggest for this case. If you feel like building on the master branch, it should be working for your toy example. If that string starts with a , -, or + though, the parser will assume it is genuine hunk content. I don't think there's any way around that, agreed?

git log --patch --pretty=format:'%C(red)I SHOULD BE RED'

I'm curious what your non-toy examples are.

[0xC0FFEE]

Thanks for resolving this so quickly 👍

The non-toy example is my custom git log format (git log --format=format:"%C(auto)%h %C(green)%aN%Creset %s" -p) which creates better readable diffs for me:

Before:

After:

It seems like I'm using these color patterns to identify the next commit. Without these colors it is quite hard for me to spot the next commit. Maybe there is a feature request hidden inside: visually separate the individual commits somehow.

Edit: I've noticed a similar edge case behavior when using the --stat modifier (e.g. git log --format=format:"%C(auto)%h %C(green)%aN%Creset %s" -p --stat):

When looking at the raw output:

3f0b0d2b1 0xC0FFEE bar---
 README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README.md b/README.md
index 92ab1377b..d263ae307 100644
--- a/README.md
+++ b/README.md
@@ -28,6 +28,8 @@ Neovim is a project that seeks to aggressively refactor Vim in order to:
 See the [Introduction](https://github.com/neovim/neovim/wiki/Introduction) wiki page and [Roadmap]
 for more information.

+bar
+
 Features
 --------


5b1ce00a8 0xC0FFEE foo---
 README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README.md b/README.md
index f9a9a7fe8..92ab1377b 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,7 @@
 [![Neovim](https://raw.githubusercontent.com/neovim/neovim.github.io/master/logos/neovim-logo-300x87.png)](https://neovim.io)

+foo
+
 [Documentation](https://neovim.io/doc) |
 [Chat](https://gitter.im/neovim/neovim) |
 [Twitter](https://twitter.com/Neovim)

f9055c585 Ghjuvan Lacambre LSP: enable using different highlighting rules for LSP signs (#12176)---
 runtime/doc/lsp.txt                 | 16 ++++++++++++----
 runtime/lua/vim/lsp.lua             |  8 ++++----
 runtime/lua/vim/lsp/util.lua        |  1 +
 test/functional/plugin/lsp_spec.lua |  4 ++++
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/runtime/doc/lsp.txt b/runtime/doc/lsp.txt
index 2d0bba0ff..8140b6a15 100644
--- a/runtime/doc/lsp.txt
+++ b/runtime/doc/lsp.txt
@@ -163,13 +163,21 @@ name: >
 LSP HIGHLIGHT                                                    *lsp-highlight*

It seems like a good starting point for lines to parse are all lines after a line starts with diff , however FWICT there doesn't seem to be an easy way to find the end? Maybe the first line after the header[1] of a line starting with diff, which does neither start with , + nor -?

[1]

diff --git a/README.md b/README.md
index 92ab1377b..d263ae307 100644
--- a/README.md
+++ b/README.md
@@ -28,6 +28,8 @@ Neovim is a project that seeks to aggressively refactor Vim in order to:

[dandavison]

Cool! That's helpful -- I'm trying to get straight in my mind the different sorts of log customizations that people might have and whether/how they can be handled. (I'll think about the other edge case you bring up later.)

It seems like I'm using these color patterns to identify the next commit. Without these colors it is quite hard for me to spot the next commit. Maybe there is a feature request hidden inside: visually separate the individual commits somehow.

Have you experimented with --commit-style box and --commit-color?

[0xC0FFEE]

Thanks for pointing me towards --commit-style which I didn't knew about! However I personally find it a bit too much. Personally I like how easy the colored commit messages are on my eyes. I also really like how densely all relevant information can be displayed with the custom log format in a single line. Another advantage to me is, that they look the same whether I'm looking at git log or git log -p.

Currently I'm not sure if there is a feature request at all, as delta supports custom colors in git log now. And sometimes less is more :-). I'll keep an eye on this when looking at diffs and maybe open a new feature request if I'm more confident on what would be helpful.

Thanks again for tackling this so quickly. If you would like me to open another report for the --stat edge case, just let me know!