Fix interdiff context trimming when output is colorized

[kerneltoast]

When interdiff's output is set as colorized, that means the output from the diff execution inside interdiff contains color escape codes. The color escape codes break trim_context(), which doesn't expect a line to start with an escape character.

Fix trim_context() to handle colorized output from diff.

[kerneltoast]

FYI, even with this fix I still observe issues with colorized output where the unline is printed:

[codecov]

Codecov Report

❌ Patch coverage is 33.33333% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.30%. Comparing base (ecb9554) to head (755c9fd).
⚠️ Report is 5 commits behind head on master.

Files with missing lines	Patch %	Lines
src/interdiff.c	33.33%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #119      +/-   ##
==========================================
- Coverage   82.39%   82.30%   -0.10%     
==========================================
  Files           5        5              
  Lines        4130     4137       +7     
  Branches      983      985       +2     
==========================================
+ Hits         3403     3405       +2     
- Misses        727      732       +5     

Flag	Coverage Δ
unittests	82.30% <33.33%> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[twaugh]

Oh, I see, the colour support isn't as easy as I'd hoped.

Probably the answer is not to pass through the --color options at all to the internal diff invocations and instead generate our own, like:

static void output_colored_line(FILE *out, const char *line, char prefix) {
    if (output_color_mode == 0) { // never
        fputs(line, out);
    } else if (output_color_mode == 2) { // always  
        switch (prefix) {
            case '+': fprintf(out, "\033[32m%s\033[0m", line); break; // green
            case '-': ...; break; // red
            case '@': ; break; // cyan
            default:  fputs(line, out); break;
        }
    }
}

[twaugh]

Added a test case for this in #121

[kerneltoast]

Oh, I see, the colour support isn't as easy as I'd hoped.

Probably the answer is not to pass through the --color options at all to the internal diff invocations and instead generate our own, like:

static void output_colored_line(FILE *out, const char *line, char prefix) {
    if (output_color_mode == 0) { // never
        fputs(line, out);
    } else if (output_color_mode == 2) { // always  
        switch (prefix) {
            case '+': fprintf(out, "\033[32m%s\033[0m", line); break; // green
            case '-': ...; break; // red
            case '@': ; break; // cyan
            default:  fputs(line, out); break;
        }
    }
}

Agreed, I had come to the same conclusion as well :)

[twaugh]

Think I have a workable fix in #123.
Is --color=auto too bold a default? Maybe it should default to never.

[kerneltoast]

I think automatic color is fine since it's in line with diff's default behavior.

[kerneltoast]

I think automatic color is fine since it's in line with diff's default behavior.

Oops, I was thinking of git diff's default behavior. diff doesn't colorize by default; nonetheless, I think --color=auto by default is the right choice going off of git diff. 🙂

[twaugh]

Closing in favour of #123