From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [PATCH v2 1/2] grep: add option to show whole function as context
Date: Tue, 02 Aug 2011 20:08:50 +0200 [thread overview]
Message-ID: <4E383D32.5090604@lsrfire.ath.cx> (raw)
In-Reply-To: <7vei14hgcd.fsf@alter.siamese.dyndns.org>
Am 02.08.2011 01:17, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Add a new option, -W, to show the whole surrounding function of a match.
>
> Thanks, will queue both patches.
>
> It feels somewhat dirty to take the range between the previous "funcname"
> and the next "funcname" and consider it the whole function, as if there is
> nothing outside the function, though. I certainly understand that this is
> a natural and unfortunate consequence that "funcname" is a mechanism
> designed to mark only the _beginning_, and we didn't have any need for a
> mechanism to mark the _end_.
>
> I am not complaining; just making an observation. I do not offhand have a
> suggestion for improving this, and I think the obvious "then let's come up
> with another configuration to mark the end" is not an improvement but
> making things worse, so...
A certain amount of dirtyness is unavoidable unless we use a real
parser. Apropos, labels are function boundaries as well, so there we
have another limitation (i.e. we won't get a function whole if it
contains labels without leading whitespace).
Ideally I'd like to see the whole function text up to the closing brace
but including any leading comments, if present. Which is even more
complicated, of course.
For C-style and Shell files, /^}/ would probably suffice as a regex to
find function endings..
First I'm curious to see how useful the simple start-to-start heuristic
is, though. Even the -[ABC] options are kind of fuzzy -- how do you
know the number is high enough before running grep? Let's see how far
this quick and dirty approach to present a smarter context can take us.
René
next prev parent reply other threads:[~2011-08-02 18:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-31 15:59 [PATCH] grep: add option to show whole function as context René Scharfe
2011-07-31 17:34 ` Sverre Rabbelier
2011-08-01 15:37 ` René Scharfe
2011-08-01 15:39 ` Sverre Rabbelier
2011-08-01 17:20 ` René Scharfe
2011-08-01 17:20 ` [PATCH v2 1/2] " René Scharfe
2011-08-01 23:17 ` Junio C Hamano
2011-08-02 18:08 ` René Scharfe [this message]
2011-08-01 17:22 ` [PATCH v2 2/2] grep: long context options René Scharfe
2011-08-02 1:01 ` Tait
2011-08-02 17:24 ` René Scharfe
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=4E383D32.5090604@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=srabbelier@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).