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