Re: [bug-grep] Re: [patch #3644] --initial-tab and 3 newly colorized items

[Charles Levert]

* On Friday 2005-01-28 at 07:49:44 -0800, Elliott Hughes wrote:
> On Jan 27, 2005, at 23:52, Aharon Robbins wrote:
> 
> >Removing the coloring code would solve all the problems quite neatly.
> >Write a separate program that colors matched text for those who
> >want it.
> 
> the trouble with that idea is that the separate program would have to 
> duplicate all grep's work to know where the pattern matched.

Even without bringing the subject of colors, the standardized output of
grep does lack unambiguous structure.  Consider using "-H" (or grepping
through several files which will effectively turn it on automatically).
Each matching line is now prependend with "filename:".  But consider
these two possibilities for "grep -H baz":

  -- File "foo" contains the line "bar:baz"; the output will be

        foo:bar:baz

  -- File "foo:bar" contains the line "baz"; the output will be

        foo:bar:baz

Any output among the following styles could have avoided that problem:

        foo\:bar:baz
        "foo:bar":baz
          (assuming double quotes in the filename would be escaped)

Other options such as "-n" and "-b" can show similar problems if used
with "-H".

Colorizing is neither a generic nor a foolproof way to achieve structure
and remove ambiguity (both the filename and content might already contain
SGR sequences), but it can be helful.  If the output of UNIX grep had
initially been designed to show unambiguous and exhaustive structure
(and a familiar looking and pervasively-used one), I would then have
advocated that an external colorizing filter be used on that output.

Compare this with the output of unidiff.  At least every content line
is prepended with a character, be it ' ', '-', or '+', so there is
no ambiguity there.  Just consider how confusing not prepending lines
common to both files with ' ' would have been.
(There is one ambiguity if a line of content exclusive to the old file has
the form "-- filename ..." and each line is considered in isolation [such
as what a unidiff-output colorizing filter might naively attempt to do],
but that can be resolved by considering the previous "@@" header line.
A better design for unidiff would have been to use "@---" and "@+++"
for header lines to announce files, but it's too late for that.)


> i'll admit to having been skeptical about grep --color; i think color 
> ls(1) is one of the worst ideas in the whole GNU universe,

I does get more usable when you tone down the number of things it
colorizes, though (and get rid of the default blue-foreground-alone
for directories; 11% luminosity *is* unreadable on a dark background,
for terminals that take color names at face value).

But to each his own and I can understand and respect.


> even include 
> the various GNOME/GTK+ crimes. "ls -F" does a similar job without being 
> confusing, obscurantist, or ugly.

"ls -F" is ok for directories and '/', but it does have an ambiguity
problem with the other suffix characters with which a filename might
already end (although that would be queer, but one does not own all the
files on a multi-user system).


> don't confuse minimalism with asceticism!

Plus colorizing doesn't add that much code, at least compared to the
relative size of the regexp engine that is needed.

I do know about minimization (a form of optimization, which is not
necessarily minimalism):  I did prefer having just one new GREP_COLORS
variable that would be it once and for all as far as colorizing is
concerned, instead of adding one variable for each new colorizable item,
as a previous proposal on Savannah implemented.  Also compare my parser
for GREP_COLORS to that of LS_COLORS and you will see how much simpler
it is.

Although minimalism can be considered, robustness and transparency
(non-ambiguity and structure) just have higher priority for me.



Please forgive the non-minimalism of my emails.   :-)