Closed joshtriplett closed 4 months ago
Brilliant! This is a great advance. I had switched to using rg --json
exclusively but I know people will want to use git grep
and other greps. (And the git grep -W
option is interesting; delta tries to be helpful with it in combination with --navigate
, allowing jumping between search hits with n/N)
Hey @joshtriplett, thanks for this.
I was also thinking about reading custom git grep
colors from .gitconfig
to parse the output correctly.
Do you plan a follow up pull request for that?
If anyone does work on reading colors from .gitconfig
, I just want to point out this hack that's been in the codebase for a long time. What it's doing is checking whether git has added any colors other than the default added/removed colors; if the answer is "yes" then we output a raw line e.g. because this might be git outputting "color-moved" colors. The hack is that the added/removed colors are hardcoded as red/green. Just mentioning in case it can also be made more robust (although I don't think anyone's ever complained).
Parse filename unambiguously using color escape sequences, to handle cases where separators like
-
appear in the filename.git grep
, by default, emits ANSI color escape sequences around the filename, separator, and line number. Parse these if available.Add tests for filenames that previously failed to parse correctly.
Fixes: #1083
Before:![delta-before](https://github.com/dandavison/delta/assets/162737/5258129e-a99c-47f9-af13-5973019d981b)
After:![delta-after](https://github.com/dandavison/delta/assets/162737/e7f20feb-5b99-43e6-b2e3-f156c596e39e)
This currently assumes the default colors, and will fall back to the previous parsing if any of the colors have been changed. This is an issue elsewhere in delta as well; for instance, if
color.grep.match
has been changed then delta won't highlight matches. I think this would be easy to fix, by parsing git's color configuration (which I implemented inanstyle-git
), rendering those color sequences to ANSI escapes, and using those in the regex rather than hardcoded ones. However, I think that should be a separate PR.