Re: [PATCH] grep: add known breakage of coloring when using extended patterns

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

 



Renà Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes:

> Aggregating the set of matching characters and passing them back
> during expression evaluation can be more efficient, yes, as it would
> avoid calling regexec() on the printed lines again only to find out
> what to color.  But I wouldn't call it easy.  E.g. how to return the
> set of matching characters in the following case?
>
> 	$ git grep --color -e foo --and -e bar

I would naÃvely expect each of the "grep_expr" in the parsed grep tree to
have not just a one-bit "hit", but rm_so/rm_eo pair, but as I said, I was
asleep while "coloring the parts that matched" discussion was in progress
;-)

But

> Also GNU grep doesn't only color the first sufficient match.
> E.g. this will color both b and d:
>
> 	$ echo abcde | grep --color -e b -e d

that is probably a useful thing to have.  Obviously, my suggestion should
optimize away the match with 'd' to begin with, so keeping rm_so/rm_eo
pair would not help painting d at all.  Worse yet, I would expect that

	$ echo abcdeabcde | grep --color -e b -e d

would need to paint all occurrences for such a purpose, so obviously you
would need an extra pass to find all potential hits.  Ugly and makes me
personally wonder if it is really worth it, but the user is explicitly
asking for --color and is prepared to pay the price, so it probably is Ok.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]