On Fri, Aug 1, 2008 at 9:30 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Thanks.
>
> I do not talk Ruby,
You're really missing into something ;)
> so I'll wait for a few days to hear any one of the
> following happen before deciding what to do with this patch:
>
> (1) Yeah, this is a sufficient and necessary set of keywords, and it
> would make my Ruby life so much better;
>
> (2) This might be a good start but you need to cover this and that
> keywords as well;
>
> (3) This will misidentify a line that is not the beginning of a
> definition, and should not be applied;
>
> Needless to say, "Here is a better patch" is appreciated if somebody says
> (2) or (3).
I wasn't sure about the completeness of the regexp myself, which is
why I asked in #ruby on freenode for additional suggestions. The only
reply I got was an idea to add a number of block-based coding sections
such as Procs an Threads by matching .*\.new ({|do) as well.
This is something I had been thinking about myself, but I decided to
discard the idea because the current chunk text detection in git does
not have a way to say 'this is the end of a function, so get back to
the previous chunk (con)text' instead of using the last chunk text: so
if I have methodx followed by methody and make a change near the top
of methody I get methodx in the chunk text.
This limitation, that affects all funcname parsers, has kept me from
adding Proc, Thread and other anonymous code blocks to the Ruby
funcname, because having the proper context for changed code after an
anonymous block is IMO better than having specific context in the
anonymous block itself.
OTOH, if the funcname capability was expand to a full stack
manipulation (push chunk text, pop chunk text) ... (and yes, if I ever
find a sane way to do it myself I *will* provide a patch)
--
Giuseppe "Oblomov" Bilotta
--
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
