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

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Am 02.05.2011 13:35, schrieb Bert Wesarg:
> The coloring code does not respect the extended pattern format, expose
> this with an known breakage test.
>
> Signed-off-by: Bert Wesarg<bert.wesarg@googlemail.com>
> ---
>   t/t7812-grep-color.sh |   25 +++++++++++++++++++++++++
>   1 files changed, 25 insertions(+), 0 deletions(-)
>   create mode 100755 t/t7812-grep-color.sh
>
> diff --git a/t/t7812-grep-color.sh b/t/t7812-grep-color.sh
> new file mode 100755
> index 0000000..2cffff3
> --- /dev/null
> +++ b/t/t7812-grep-color.sh
> @@ -0,0 +1,25 @@
> +#!/bin/sh
> +
> +test_description='git grep --color
> +'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> +	test_commit initial input "foo bar baz
> +bar baz
> +"
> +'
> +
> +cat>expected<<EOF
> +input<CYAN>:<RESET><BOLD;RED>foo<RESET>  bar baz
> +EOF
> +
> +
> +test_expect_failure 'grep coloring does not honor boolean algebra' '
> +	git grep --color -e foo --or \( -e bar --and --not -e baz \) |
> +		test_decode_color>actual
> +    test_cmp expected actual
> +'
> +
> +test_done

The current code highlights the given search terms ("atoms").  You 
expect the matching part of a line to be highlighted instead.  Another 
example with differing results between the two ways is this:

	$ git grep -v -e foo --and -e bar

The first one was easy to implement and useful already.  I wonder how to 
implement the second one (I couldn't think of an easy way back then) and 
also if we really prefer it to the current behaviour in the first place.

The twisted logic that convinced me to forget about the issue goes like 
this: Even by giving negative search terms, the user is expressing a 
certain value of interest in them; highlighting these atoms even in 
lines which were not matched by them is a courtesy.

René