---------- Forwarded message ----------
From: Nathaniel Flath <flat0103@gmail.com>
Date: Sun, Aug 16, 2009 at 10:32 PM
Subject: Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does
not match all Java 1.5+ function definitions.
To: Chong Yidong <cyd@stupidchicken.com>


And again.


On Fri, Aug 7, 2009 at 7:32 AM, Nathaniel Flath <flat0103@gmail.com> wrote:

> Just pinging this out again.
>
>
> On Tue, Jul 28, 2009 at 9:46 PM, Nathaniel Flath <flat0103@gmail.com>wrote:
>
>> There did turn out to be a few problems with that regexp - the updated one
>> is:
>>
>> (defvar cc-imenu-java-generic-expression
>>   `((nil
>>      ,(concat
>>        "[" c-alpha "_][\]\[." c-alnum "_<> ]+[ \t\n\r]+" ; type spec
>>        "\\([" c-alpha "_][" c-alnum "_]+\\)" ; method name
>>        "[ \t\n\r]*"
>>        ;; An argument list htat is either empty or contains any number
>>        ;; of arguments.  An argument is any number of annotations
>>        ;; followed by a type spec followed by a word.  A word is an
>>        ;; identifier.  A type spec is an identifier, possibly followed
>>        ;; by < typespec > possibly followed by [].
>>        (concat "("
>>                "\\("
>>                   "[ \t\n\r]*"
>>                   "\\("
>>                      "@"
>>                      "[" c-alpha "_]"
>>                      "[" c-alnum "._]""*"
>>                      "[ \t\n\r]+"
>>                   "\\)*"
>>                   "\\("
>>                      "[" c-alpha "_]"
>>                      "[\]\[" c-alnum "_.]*"
>>                      "\\("
>>                         "<"
>>                         "[ \t\n\r]*"
>>                         "[\]\[.," c-alnum "_<> \t\n\r]*"
>>                         ">"
>>                      "\\)?"
>>                      "\\(\\[\\]\\)?"
>>                      "[ \t\n\r]+"
>>                   "\\)"
>>                  "[" c-alpha "_]"
>>                  "[" c-alnum "_]*"
>>                  "[ \t\n\r,]*"
>>                "\\)*"
>>               ")"
>>            "[ \t\n\r]*"
>>        "{"
>>        )) 1))
>>   "Imenu generic expression for Java mode.  See
>> `imenu-generic-expression'.")
>>
>> I ended up just splitting out the annotations from the type from the
>> identifier name to make it easier in the argument list.  A file that
>> displays some of the matches/non-matches is:
>>
>> //(setq imenu-generic-expression cc-imenu-java-generic-expression)
>>
>> public class Test {
>>
>>     void fun1() { }
>>     void fun2( int a ) { }
>>     void fun3( int a, int b ) { }
>>     List<String > fun4() { }
>>     Map< String,String > fun5() { }
>>     void fun6( @NonNull int a ) { }
>>     void fun7( @NonNull int b, @NonNull int c ) { }
>>     void fun8( @NonNull List<String> a ) { }
>>     void fun9( @NonNull List<List<String >> a ) { }
>>     void fun10( @NonNull int[] a) { }
>>     void fun11( List< class.innerclass > foo ) { }
>>     voif fun12( class.innerclass< Integer> foof ) { }
>>
>>     else if( a ) { }
>>     else if( a < b ) { }
>>     else if( a < b && b > a ) { }
>>     else if(  a ) { }
>>     else if( a.b ) { }
>> }
>>
>> the 'funX' should all be matched, with no 'else if's
>>
>>
>> On Tue, Jul 28, 2009 at 8:28 PM, Chong Yidong <cyd@stupidchicken.com>wrote:
>>
>>> Alan Mackenzie <acm@muc.de> writes:
>>>
>>> > OK.  I've not looked at it in all that great detail, and haven't tried
>>> > it out yet.  I'm not actually a Java hacker.
>>> >
>>> > How confident are you that your proposed regexp won't spuriously match
>>> > things with "less than" or "greater than" tokens?  Or, if it will,
>>> would
>>> > these matches be rare enough that we needn't worry too much?
>>> >
>>> > Is there any chance you could send me a test file showing a typical
>>> > generic construct that the new regexp would match, and possibly
>>> > constructs with "less/greater than" which it "doesn't quite" match?
>>>
>>> By the way, it might be good to accumulate a test suite for CC mode,
>>> along the lines of etc/compilation.txt.  I don't know if you already
>>> have something like that; if so, we can put it in the new test/
>>> directory.
>>>
>>> (We should probably move etc/compilation into test/ also.)
>>>
>>
>>
>