Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1.1: Type: text/plain, Size: 409 bytes --]

I was using Imenu, and noticed that it currently doesn't recognize Java
functions with either:
Generics e.g : public List<String> foo() { ...
or annotated arguments, e.g : public void foo( @NonNull bar ) {


The issue was the variable cc-imenu-java-generic-expression.

Attached is my patch which modifies this variables to accept all function
definitions and should fix this issue.


Thanks!
Nathaniel Flath

[-- Attachment #1.2: Type: text/html, Size: 458 bytes --]

[-- Attachment #2: cc-menus.patch --]
[-- Type: text/x-patch, Size: 1079 bytes --]

index b151bd0..8a87448 100644
--- a/lisp/progmodes/cc-menus.el
+++ b/lisp/progmodes/cc-menus.el
@@ -149,17 +149,18 @@ A sample value might look like: `\\(_P\\|_PROTO\\)'.")
 (defvar cc-imenu-java-generic-expression
   `((nil
      ,(concat
-       "[" c-alpha "_][\]\[." c-alnum "_]+[ \t\n\r]+" ; type spec
+       "[" c-alpha "_][\]\[." c-alnum "_<> ]+[ \t\n\r]+" ; type spec
        "\\([" c-alpha "_][" c-alnum "_]+\\)" ; method name
        "[ \t\n\r]*"
        ;; An argument list that is either empty or contains at least
-       ;; two identifiers with only space between them.  This avoids
+       ;; two words with whitespace in between them.  Words are
+       ;; identifiers and <>@ characers.  This prevents us from
        ;; matching e.g. "else if (foo)".
        (concat "([ \t\n\r]*"
-	       "\\([\]\[.," c-alnum "_]+"
+	       "\\([\]\[.," c-alnum "_@<> ]+"
 	       "[ \t\n\r]+"
 	       "[\]\[.," c-alnum "_]"
-	       "[\]\[.," c-alnum "_ \t\n\r]*"
+	       "[\]\[.," c-alnum "_ \t\n\r@<> ]*"
 	       "\\)?)")
        "[.," c-alnum "_ \t\n\r]*"
        "{"

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

Has anybody looked at this yet?

On Sat, Jul 18, 2009 at 8:27 AM, Nathaniel Flath <flat0103@gmail.com> wrote:

> I was using Imenu, and noticed that it currently doesn't recognize Java
> functions with either:
> Generics e.g : public List<String> foo() { ...
> or annotated arguments, e.g : public void foo( @NonNull bar ) {
>
>
> The issue was the variable cc-imenu-java-generic-expression.
>
> Attached is my patch which modifies this variables to accept all function
> definitions and should fix this issue.
>
>
> Thanks!
> Nathaniel Flath
>

[-- Attachment #2: Type: text/html, Size: 863 bytes --]

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Glenn Morris]

Nathaniel Flath wrote:

> Has anybody looked at this yet?

Perhaps not.

It is better to send bugs to the bug list (with M-x report-emacs-bug),
since that creates a more permanent record that is less likely to be
overlooked.

Filed as:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3910

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Alan Mackenzie]

Hi, Nathaniel,

sorry about the delay replying - I'm the guy who does the CC Mode
things, and sadly there's only one of me at the moment.

On Sat, Jul 18, 2009 at 08:27:10AM -0700, Nathaniel Flath wrote:
> I was using Imenu, and noticed that it currently doesn't recognize Java
> functions with either:
> Generics e.g : public List<String> foo() { ...
> or annotated arguments, e.g : public void foo( @NonNull bar ) {

CC Mode has got a bit behind in handline C++ templates and Java generics
(which are essentially the same thing from Emacs's point of view).
There's quite a bit of work to be done on updating Java Mode's support
for recent enhancements to the language.

<rant>
Misusing "<" and ">" as template/generic delimiters was an egregious
"design" decision by the C++ people, and even worse by the Java team who
ought to have learned from C++'s mistake - other tokens could have been
built which would have been both easy on the eye and unambiguous enough
to parse syntactically.

There are pieces of C++ code which need a compiler (or some equivalent
tool) to distinguish "less than" from "template start".  There might
also be similar Java code, I'm not sure.  As a result, syntactic
analysis of C++ (and maybe Java) code which contains "<" and ">" is
either difficult or impossible in the general case.
</rant>

> The issue was the variable cc-imenu-java-generic-expression.

> Attached is my patch which modifies this variables to accept all
> function definitions and should fix this issue.

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?

Thanks!

> Nathaniel Flath

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> sorry about the delay replying - I'm the guy who does the CC Mode
> things, and sadly there's only one of me at the moment.
>
> On Sat, Jul 18, 2009 at 08:27:10AM -0700, Nathaniel Flath wrote:
>> I was using Imenu, and noticed that it currently doesn't recognize Java
>> functions with either:
>> Generics e.g : public List<String> foo() { ...
>> or annotated arguments, e.g : public void foo( @NonNull bar ) {
>
> CC Mode has got a bit behind in handline C++ templates and Java generics
> (which are essentially the same thing from Emacs's point of view).
> There's quite a bit of work to be done on updating Java Mode's support
> for recent enhancements to the language.
>
> <rant>
> Misusing "<" and ">" as template/generic delimiters was an egregious
> "design" decision by the C++ people,

It was actually a design decision by the Ada people.  Ada uses <...> for
constraints in lots of contexts, and generics parameters are
constraints.

It was abysmally stupid to let C++ templates look like Ada generics, in
particular since C++ has << and >> operators.  But then C++ syntax is a
collection of stupidities, parseable only by hand-written recursive
descent parsers and they still tend to get the corner cases wrong (while
human readers tend to get surprised by quite more cases).  And it is
already stupid to have a preprocessor with a different syntax, but that
particular stupidity is inherited.

C++ is an attempt to cram not only everything that can be somehow made
to fit into the functionality, but also into the syntax.  And that's
insane.

> There are pieces of C++ code which need a compiler (or some equivalent
> tool) to distinguish "less than" from "template start".  There might
> also be similar Java code, I'm not sure.  As a result, syntactic
> analysis of C++ (and maybe Java) code which contains "<" and ">" is
> either difficult or impossible in the general case.

And nowadays, >> for ending two nested template parameter sets is
supposed to be handled properly by the compiler.  Making the problem
still more complex.

In a well-designed language, recognizing syntactic elements does not
need much context.  Nobody wants to read computer languages in the style
of classic Greek where a single sentence spreads itself over more than
one page and happens not to actually have a verb predicate, so you go
back and forth until you finally manage to make sense of the nested
somewhat arbitrary constructs.

If I wanted to do that, I would learn German.  Oh, wait...

-- 
David Kastrup

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Chong Yidong]

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

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1: Type: text/plain, Size: 3449 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4727 bytes --]

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1: Type: text/plain, Size: 3729 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5175 bytes --]

Fwd: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1: Type: text/plain, Size: 4218 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6187 bytes --]

Re: Fwd: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Alan Mackenzie]

Hi, Nathaniel,

On Sun, Aug 16, 2009 at 10:33:03PM -0700, Nathaniel Flath wrote:
> ---------- 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.

Sorry.  I've had some heavy personal stuff to deal with in the last few
weeks.  None of us actually gets paid for maintaining Emacs.  I'm still
not fully up to scratch for doing software.

Also, it looks like your change is quite a substantial one, so I'll have
to ask you to sign (paper) copyright assignment forms (to the Free
Software Foundation) before installing it into CC Mode.  Or have you
already been through this?  This is standard FSF policy, and though
ostensibly you're giving something away, in reality you're not.  You
retain the right to do as you wish with your own stuff, but you get the
protection of FSF's lawyers should anybody ever violate your copyright.

> There did turn out to be a few problems with that regexp - the updated
> one is:

Could you tell me please what those problems were (perhaps with a
fragment of Java source where the problems became apparent).

> (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

OK.  Again, how sure are you that the new regexp won't spuriously match
things with "less than" or "greater than" tokens?

Thanks for taking the trouble with this patch, despite all the tedium
I've been causing you.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Fwd: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1: Type: text/plain, Size: 5444 bytes --]

Don't worry about the long delay- I understand that nobody's being paid for
Emacs, I just wanted to make sure that my patch hasdn't been lost.  I hope
the personal stuff that came up ends up OK for you.  Good luck!

I have not signed any copyright assignment forms to the FSF - I'll print
them out and mail them in on Monday.

The problems with the initial regexp was that it could count whitespace as a
type in variables inside words, so it would accept
    else if(  a ) {
        ....

as a function, even though it would reject
    else if( a ) {
        ...

I fixed this by modifying the regexp to split out checking for annotations,
types, and variable name seperately, while the original essentially had the
mashed together(It was probably based too closely of the regexp I was
modifying).

I'm pretty sure the new regexp works for expressions with < and > tokens - I
have the test file that I sent, and have been using this regexp since I last
emailed it without any false positives or missed functions.

Thanks for taking the time reviewing this patch!

Thanks,
Nathaniel Flath
On Sat, Aug 22, 2009 at 7:17 AM, Alan Mackenzie <acm@muc.de> wrote:

> Hi, Nathaniel,
>
> On Sun, Aug 16, 2009 at 10:33:03PM -0700, Nathaniel Flath wrote:
> > ---------- 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.
>
> Sorry.  I've had some heavy personal stuff to deal with in the last few
> weeks.  None of us actually gets paid for maintaining Emacs.  I'm still
> not fully up to scratch for doing software.
>

> Also, it looks like your change is quite a substantial one, so I'll have
> to ask you to sign (paper) copyright assignment forms (to the Free
> Software Foundation) before installing it into CC Mode.  Or have you
> already been through this?  This is standard FSF policy, and though
> ostensibly you're giving something away, in reality you're not.  You
> retain the right to do as you wish with your own stuff, but you get the
> protection of FSF's lawyers should anybody ever violate your copyright.
>
> > There did turn out to be a few problems with that regexp - the updated
> > one is:
>
> Could you tell me please what those problems were (perhaps with a
> fragment of Java source where the problems became apparent).
>
> > (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
>
> OK.  Again, how sure are you that the new regexp won't spuriously match
> things with "less than" or "greater than" tokens?
>
> Thanks for taking the trouble with this patch, despite all the tedium
> I've been causing you.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

[-- Attachment #2: Type: text/html, Size: 7333 bytes --]

Re: Fwd: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath]

[-- Attachment #1: Type: text/plain, Size: 3559 bytes --]

Any new on this yet - either recieving the forms or concerns about the code?

Thanks,
Nathaniel Flath

On Tue, Sep 29, 2009 at 2:46 PM, Nathaniel Flath <flat0103@gmail.com> wrote:

> I received the forms yesterday and sent them back, so the FSF should get
> them in about a week.  The contract I signed mentioned I was recieving a
> dollar for the copyright - any idea when I can expect it?
>
> I found another issue whith that regex, which was it didn't recognize
> functions that throw exceptions.  I fixed that, and have been using it since
> September with no additional issues.
>
> (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 arppguments.  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,]*"
>                "\\)*"
>                ")"
>                "[.," c-alnum " \t\n\r]*"
>                "{"
>                )) 1))
>   "Imenu generic expression for Java mode.  See
> `imenu-generic-expression'.")
>
>
> Thanks,
> Nathaniel Flath
>
>
> On Sat, Aug 22, 2009 at 9:32 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
>
>> > I have not signed any copyright assignment forms to the FSF - I'll print
>> > them out and mail them in on Monday.
>>
>> The way it works is as follows: fill the form below, and email it as
>> instructed, at which point the FSF will send you the form you need
>> to sign.
>>
>>
>>        Stefan
>>
>>
>> Please email the following information to assign@gnu.org, and we
>> will send you the assignment form for your past and future changes.
>>
>> Please use your full legal name (in ASCII characters) as the subject
>> line of the message.
>> ----------------------------------------------------------------------
>> REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
>>
>> [What is the name of the program or package you're contributing to?]
>> Emacs
>>
>> [Did you copy any files or text written by someone else in these changes?
>> Even if that material is free software, we need to know about it.]
>>
>>
>> [Do you have an employer who might have a basis to claim to own
>> your changes?  Do you attend a school which might make such a claim?]
>>
>>
>> [For the copyright registration, what country are you a citizen of?]
>>
>>
>> [What year were you born?]
>>
>>
>> [Please write your email address here.]
>>
>>
>> [Please write your postal address here.]
>>
>>
>>
>>
>>
>> [Which files have you changed so far, and which new files have you written
>> so far?]
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4996 bytes --]

Re: Fwd: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Chong Yidong]

Nathaniel Flath <flat0103@gmail.com> writes:

> Any new on this yet - either recieving the forms or concerns about the
> code?

You're not yet entered in the list of people who've assigned copyright.
It sometimes takes a few weeks if the FSF copyright clerk has a lot of
work going on; if you haven't heard back in another week or so, send me
a private email and I'll inquire for you.