🐛 Some theme options are not working with `--color-only` enabled

[renard]

When running delta in a standalone mode (no git) with --color-only to keep a diff / patch compatible patch some theming options such as --file-style or --hunk-header-style (same with --hunk-header-decoration-style) are not operational:

Is there a way to highlight file headers and hunks delimiter in a specific colour?

Diff file:

--- 1	2020-11-23 12:51:34.434055926 +0000
+++ 2	2020-11-23 12:52:06.242055415 +0000
@@ -11,7 +11,7 @@
                                      style plain --hunk-style plain`.
         --dark                       Use default colors appropriate for a dark terminal background. For more control,
                                      see the other color options.
-    -h, --help                       Prints help information
+    -h, --HELP                       Prints help information
         --highlight-removed          Apply syntax highlighting to removed lines. The default is to apply syntax
                                      highlighting to unchanged and new lines only.
         --keep-plus-minus-markers    Prefix added/removed lines with a +/- character, respectively, exactly as git does.

TIA.

[dandavison]

Hi @renard, thanks for this! Short answer: yes, I think there are more improvements we can make to --color-only. We should be able to color all elements as long as we are not making any "structural" changes (e.g. decorations).

Until recently, there had been some bugs causing --color-only to create invalid patch output, when used in combination with certain options. For many delta users this comes up when using git add -p. Thanks to the work of @ulwlu, these are mostly, or perhaps entirely, gone now. See e.g. #320. I think perhaps we can characterize this program of work as follows:

0. There were bugs relating to invalid patches under --color-only
1. We introduced much better test coverage and fixed bugs, but erring on the side of aggressively eliminating features from --color-only to ensure that a valid (if vanilla in terms of coloring) patch was produced.
2. Now that we have good test coverage we should be in a better position to revisit and allow color where possible without allowing any decorations/structural changes to the patch.

cc @ulwlu what do you think?

Hi, my thought is same.

we should be in a better position to revisit and allow color where possible without allowing any decorations/structural changes to the patch

0-1 are true, maybe I can look into it to make --color-only better. I'm going to find a way to allow color without changing structural. It takes me few days maybe.

[dandavison]

Thanks @ulwlu, that would be fantastic if you have time.

P.S.

Currently, I'm busier than I expected so not working yet.
I'm going to start on this Sunday.

-- P.S. 2020-11-29

Sorry again, but still quite busy with my job.
It will take me a week.

@dandavison

Hi, I'm currently working on this, however, doesn't end-to-end-test fail with current master?

Even though unit-test succeeds, end-to-end-test fails with below stderr.

make: *** [end-to-end-test] Error 1

--
P.S.

I realized this is a bug from tests.
I'm gonna fix this at first.

[dandavison]

Thanks @ulwlu! I noticed this yesterday but didn't have a chance to fix. Fixed now I believe. ed39e4c

Now, what I need to work out is why CI was not failing. Locally, the shell scripts exit with a non-zero error status. cc @marcoieni (but you don't have any obligations after all your work! :) )

@dandavison

why CI was not failing

I think CI succeeds because it passes argument.
If we command locally as same as shell of CI, I confirm it works.

[dandavison]

@ulwlu Let's discuss in #421