bug-grep
[Top][All Lists]
Advanced

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

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


From: Elliott Hughes
Subject: Re: [bug-grep] Re: [patch #3644] --initial-tab and 3 newly colorized items
Date: Fri, 28 Jan 2005 07:49:44 -0800

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.

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

when i gave "grep --color" a go, i was surprised to find that it's actually useful. especially when you have a complicated regular expression that you're playing with to make it more/less inclusive, because you can see which part of the input it matched. information that otherwise isn't available.

i liked it so much, i copied it for my editor's find/replace function [actually, i guess i was imitating those scripts that color patches, but same thing]:

  http://www.jessies.org/~enh/software/edit/

although you can't see from the screenshot, it also shows the various captured groups when the user hover over a match, to make it easier to construct the replacement string. i flatter myself that my knowledge of regular expressions is pretty good, and yet i still find this useful. in fact, i've been known to play with a regular expression in my editor if i'm having trouble getting it right at the shell prompt.

don't confuse minimalism with asceticism!

--
http://www.jessies.org/~enh/





reply via email to

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