[bug-diffutils] bug#26572: problem with "diff --color": escape sequences shouldn't span multiple lines

[ian_bruce]

It appears that when "diff --color" wants to colourize a multi-line
block of text, it outputs ANSI escape sequences only at the beginning
and end of the block. However, it would be preferable if the escape
sequences were repeated at the beginning and end of each separate line.

Although this might seem inefficient, the current behavior causes bad
interactions with other software. For example, with GNU "less":

    diff --color=always -u file.c~ file.c | less -R

Only the first line of a multi-line difference gets coloured. See bug
#294, which is marked as "probably will not fix":

    With the -R flag, less only honors coloring within a single line. If
    a color extends across a newline, the color is reset at the start of
    the next line.

    The performance cost of implementing multi-line coloring is
    excessive. For example, when jumping to the end of the file using
    the G command, less could no longer just seek to the end of the
    file, but would need to read and parse any color sequences in the
    entire file.

http://www.greenwoodsoftware.com/less/bugs.html

In any situation where the output of "diff --color" is subjected to
further processing, colour-escaped text which spans multiple lines will
cause a problem, if either the first or last line of the block is
somehow removed or hidden, as with "less". The solution is to repeat the
escape sequences before and after each newline:

    <COLOUR-ESCAPE-IN>first  line of block<COLOUR-ESCAPE-OUT>\n
    <COLOUR-ESCAPE-IN>second line of block<COLOUR-ESCAPE-OUT>\n
    <COLOUR-ESCAPE-IN>third  line of block<COLOUR-ESCAPE-OUT>\n

Please consider making this small behavior change, so that
"diff --color" will be useful in situations other than direct output to
the terminal (as is clearly intended by the existence of the
"--color=always" option).


-- Ian Bruce