Added word-diff=plain colorizing support#966
Conversation
Added ADD and DEL colors for {+added+} and [-removed-] blocks of git word-diff=plain
Since git does not escape the delimiters and splits them by line, this code would sometimes end up with an incorrect highlighting.
The solution scans DEFAULT lines of the diff chunk and and adds colored cells. Since git (unlike wdiff) does not use multi-line word-diff, it works.
Test is based on diff-context-test
|
.. hey @koutcher, can you please have a look at this? 🤠 |
|
The proper way to do this would involve |
|
@koutcher I definitely missed that during my previous testing. It should be fixed now. |
|
What is the purpose of LINE_WDIFF_PLAIN ? |
|
I feel like since the line is parsed and colorized, it's not default anymore. Now it should not have an impact, but it may help in further development. |
Add --word-diff=plain colorizing support. Closes jonas#221
|
The line type is normally attached to a color line in tigrc so it wouldn't bring anything here. There was a better way to solve the cursor line problem (just change the last parameter of diff_common_add_cell to true) so I merged 9b9e6f2 and did a few adjustments to ensure it will be transparent for people not using word diff. You can have a look to koutcher@41763ae before I push it to jonas/tig. |
There's an alternative use case regarding key handling (i.e. DIFF_STAT), so I thought it may make sense if some action for diff add/del will be added.
It's absolutely fine. I love that you've added a word-diff CLI argument switch, it was definitely needed there. |
|
Point taken for the line type, we can introduce it later if there is a need for a specific action. Thanks for this contribution! |
|
When I use |
It's an intended behavior, if they have DEL and ADD colors respectively. It should look basically like an output of Stripping them is not viable as it will break commits like 4028a49. |
Added ADD and DEL colors for {+added+} and [-removed-] blocks of git word-diff=plain
Since git does not escape delimiters in word-diff, this code may produce an incorrect color output on some code that actually contains these sequences including the first commit of this PR.
It's possible to bypass this by using git color escape sequences to determine additions and deletions, but it's likely to conflict with the rest of diff parser.
(Probably) fixes #221