[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-diffutils] bug#26572: problem with "diff --color": escape sequences

From: ian_bruce
Subject: [bug-diffutils] bug#26572: problem with "diff --color": escape sequences shouldn't span multiple lines
Date: Wed, 19 Apr 2017 17:39:36 -0700

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]