patchdiff: add ruby funcname pattern

> Provide a regexp that catches class, module and method definitions in
> Ruby scripts, since the built-in default only finds classes.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>  diff.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index cbf2547..c253015 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1381,6 +1381,7 @@ static struct builtin_funcname_pattern {
>  			"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
>  			"[ 	]*([^;]*\\)$" },
>  	{ "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
> +	{ "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
>  };
>  
>  static const char *diff_funcname_pattern(struct diff_filespec *one)

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

> On Fri, Aug 1, 2008 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> 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

> Well, I forgot to say but the above was soliciting third party review;
> original submitter does not count ;-)
>
> ... nah, I am just joking.
>
> All of the things you said in the message I am responding to are good
> background information.  It would have been nicer if it were part of the
> initial message, perhaps below the three dash lines, which would have
> avoided this extra exchange.

> Thanks again for the patch.  Somewhere I heard that there are 10 Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two.  Perhaps we might even get Python
> and Perl hunk patterns (although I suspect Perl people are happy with the
> default one we stole from GNU diff) to go with it ;-).

> Thanks again for the patch.  Somewhere I heard that there are 10 Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two.  Perhaps we might even get Python
> and Perl hunk patterns (although I suspect Perl people are happy with the
> default one we stole from GNU diff) to go with it ;-).

> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>
>> On Fri, Aug 1, 2008 at 9:30 AM, Junio C Hamano <gitster@pobox.com>  
>> wrote:
>> ...
>>> 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
>
> Well, I forgot to say but the above was soliciting third party review;
> original submitter does not count ;-)
>
> ... nah, I am just joking.
>
> All of the things you said in the message I am responding to are good
> background information.  It would have been nicer if it were part of  
> the
> initial message, perhaps below the three dash lines, which would have
> avoided this extra exchange.

> Thanks again for the patch.  Somewhere I heard that there are 10  
> Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two.  Perhaps we might even get  
> Python
> and Perl hunk patterns (although I suspect Perl people are happy  
> with the
> default one we stole from GNU diff) to go with it ;-).

>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> ...
>>> I wasn't sure about the completeness of the regexp myself, which is
>> ...
> As a Ruby user, the regex for the funcname looks fine to me.

> On Sat, Aug 2, 2008 at 2:31 AM, Kevin Ballard <kevin@sb.org> wrote:
>>
>> As a Ruby user, the regex for the funcname looks fine to me.
>
> What is your opinion about the anonymous code blocks?
>
> I've been thinking that another possibility could be to have two ruby
> funcnames, a simpler one (the one I presented) that only has 'named'
> blocks, and a more thorough one that also matches up anonymous blocks.
> User could then choose which one to use in their code by having
> gitattributes such as *.rb diff=ruby or *.rb diff=ruby-full (or
> whatever else).
>
> I'm not sure this would be a sensible policy though.

>
> If you're going to get into anonymous code blocks, you're going to have a
> really tough time deciding which blocks are interesting and which aren't.
> And as you stated before, without a stack-based approach, this could really
> fall apart, as anonymous blocks are (almost) always going to be inside a
> method.

> On Sat, Aug 2, 2008 at 7:47 AM, Kevin Ballard <kevin@sb.org> wrote:
> >
> > If you're going to get into anonymous code blocks, you're going to have a
> > really tough time deciding which blocks are interesting and which aren't.
> > And as you stated before, without a stack-based approach, this could really
> > fall apart, as anonymous blocks are (almost) always going to be inside a
> > method.
> 
> I was just looking for a libxdiff issue tracker but I couldn't find one, 
> so I guess I'll ask the author directly about the possibility to 
> implement such a thing.

>> The matchit plugin for vim seems to manage (even user-defined) code
>> blocks very well, even for multi-state blocks (if ... else ... end),
>> using regexps; so maybe a reimplementation in C for libxdiff could be a
>> solution.
>
> Bzzt.  You say vi manages it with regexps, and then you go on and say that
> you therefore do _not_ want to use a regexp?
>
> BTW having funcname calculation in C was shot down by Junio as being too
> inflexible, as the user cannot add new languages without recompiling.
> That's why we have regexps now.

> On Aug 1, 2008, at 10:41 PM, Giuseppe Bilotta wrote:
>
>> On Sat, Aug 2, 2008 at 2:31 AM, Kevin Ballard <kevin@sb.org> wrote:
>
> I think it's far simpler to stick with class/module/def.
>