git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Bert Wesarg" <bert.wesarg@googlemail.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Thiago dos Santos Alvest" <hiago.salves@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] grep: add known breakage of coloring when using extended patterns
Date: Tue, 03 May 2011 19:36:39 +0200	[thread overview]
Message-ID: <4DC03D27.80803@lsrfire.ath.cx> (raw)
In-Reply-To: <7vwri8kbcy.fsf@alter.siamese.dyndns.org>

Am 03.05.2011 00:04, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> 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
> ;-)

That's true, but each one represents a single contiguous run of
characters to color.  But I meant to say that returning non-contiguous
ranges, as you can get in the --and example above, is not that easy.  To me.

Hmm, if one just wants to color the parts that triggered a match it gets
a lot easier.  Each pattern just needs to remember the last matching
offsets and then show_line can walk the expression tree to find out what
needs coloring.  Not sure about the details, though. :)

> 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.

The performance impact is low as long as there are lots more lines that
don't match than matching ones.  Which should be a given for most uses
of grep.

I always miss hit coloring if I have to use an environment that doesn't
provide , similarly to syntax highlighting, so I do think it's worth it,
for me at least.

René

      reply	other threads:[~2011-05-03 17:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 11:35 [PATCH] grep: add known breakage of coloring when using extended patterns Bert Wesarg
2011-05-02 11:41 ` Johannes Sixt
2011-05-02 11:48   ` Bert Wesarg
2011-05-02 17:14 ` René Scharfe
2011-05-02 17:37   ` Junio C Hamano
2011-05-02 21:07     ` René Scharfe
2011-05-02 22:04       ` Junio C Hamano
2011-05-03 17:36         ` René Scharfe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DC03D27.80803@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=bert.wesarg@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hiago.salves@gmail.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).