From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathaniel Flath Newsgroups: gmane.emacs.devel Subject: Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions. Date: Fri, 7 Aug 2009 07:32:31 -0700 Message-ID: <5e3a506e0908070732yc0095d5gfe72101b8843037e@mail.gmail.com> References: <5e3a506e0907180827k148fe0d1x34b89f1fedf6c79d@mail.gmail.com> <20090728101959.GA2295@muc.de> <871vo05fsl.fsf@cyd.mit.edu> <5e3a506e0907282146x549f9f8bt3412603ec86b7691@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd2950a3acc5e04708e1bbe X-Trace: ger.gmane.org 1249655616 17897 80.91.229.12 (7 Aug 2009 14:33:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2009 14:33:36 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 07 16:33:28 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MZQVc-00051O-0p for ged-emacs-devel@m.gmane.org; Fri, 07 Aug 2009 16:33:28 +0200 Original-Received: from localhost ([127.0.0.1]:49840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MZQVb-0006VU-37 for ged-emacs-devel@m.gmane.org; Fri, 07 Aug 2009 10:33:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MZQUn-000628-LA for emacs-devel@gnu.org; Fri, 07 Aug 2009 10:32:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MZQUj-00060F-Ri for emacs-devel@gnu.org; Fri, 07 Aug 2009 10:32:37 -0400 Original-Received: from [199.232.76.173] (port=44418 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MZQUj-000608-Kr for emacs-devel@gnu.org; Fri, 07 Aug 2009 10:32:33 -0400 Original-Received: from rv-out-0708.google.com ([209.85.198.240]:4118) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MZQUj-0006xq-2c for emacs-devel@gnu.org; Fri, 07 Aug 2009 10:32:33 -0400 Original-Received: by rv-out-0708.google.com with SMTP id f25so580361rvb.6 for ; Fri, 07 Aug 2009 07:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Kos2FKzdqTFgZoBvwGgx9Q2XH4lhzdbPHS2xzZMQRhU=; b=qSDbnE4SJb4HdkuXBkd7aLeiiCAWnWtccM/sRuYF23JE3LfzQtPVtLwr3hcwMjMTCl sqWAp/N/DCXidJ/q1NqQ1WQKu3tozT9DDtVFVrUGN4cAmL3T8Rgmz2MzOGpdJjIl402d tawTp/m6LDdQUpgV6xirzGeafbR+CPwZ5H1AI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KR6axoIJ5cixJa17hOitTM60i09Z8VN9KYyCL4mFo3aAQquRakf63yre5j9fSY3sIi Lv2fgBEYwm7XJBAjtrkS0Io28J+snJlhS3k/gfKgUdzZGA5JnWgA6u22JPY6JP5pcDbO BP1s9jhdRPRBv7RdmGBN9VJZG8JO/gom19aXo= Original-Received: by 10.140.187.10 with SMTP id k10mr459968rvf.109.1249655551347; Fri, 07 Aug 2009 07:32:31 -0700 (PDT) In-Reply-To: <5e3a506e0907282146x549f9f8bt3412603ec86b7691@mail.gmail.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113779 Archived-At: --000e0cd2950a3acc5e04708e1bbe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just pinging this out again. On Tue, Jul 28, 2009 at 9:46 PM, Nathaniel Flath 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 fun4() { } > Map< String,String > fun5() { } > void fun6( @NonNull int a ) { } > void fun7( @NonNull int b, @NonNull int c ) { } > void fun8( @NonNull List a ) { } > void fun9( @NonNull List> 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 wrote: > >> Alan Mackenzie 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.) >> > > --000e0cd2950a3acc5e04708e1bbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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
=A0 `((nil
=A0=A0= =A0=A0 ,(concat
=A0=A0=A0=A0=A0=A0 "[" c-alpha "_][\]\[.&= quot; c-alnum "_<> ]+[ \t\n\r]+" ; type spec
=A0=A0=A0=A0=A0=A0 "\\([" c-alpha "_][" c-alnum "_= ]+\\)" ; method name
=A0=A0=A0=A0=A0=A0 "[ \t\n\r]*"
= =A0=A0=A0=A0=A0=A0 ;; An argument list htat is either empty or contains any= number
=A0=A0=A0=A0=A0=A0 ;; of arguments.=A0 An argument is any number= of annotations
=A0=A0=A0=A0=A0=A0 ;; followed by a type spec followed by a word.=A0 A word= is an
=A0=A0=A0=A0=A0=A0 ;; identifier.=A0 A type spec is an identifier= , possibly followed
=A0=A0=A0=A0=A0=A0 ;; by < typespec > possibly= followed by [].
=A0=A0=A0=A0=A0=A0 (concat "("
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\("
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[ \t\n\r]*"
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\("
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "@"
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[" c-alpha &= quot;_]"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 "[" c-alnum "._]""*"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[ \t\n\r= ]+"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\)*&= quot;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\("= ;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[&q= uot; c-alpha "_]"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 "[\]\[" c-alnum "_.]*"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\("= ;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "<"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 "[ \t\n\r]*"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[\]\[.," c-alnum "_<= ;> \t\n\r]*"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "= ;>"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\)?&quo= t;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\= (\\[\\]\\)?"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 "[ \t\n\r]+"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 "\\)"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 "[" c-alpha "_]"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[" c-alnum &quo= t;_]*"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "[ \t\= n\r,]*"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "\\)*"=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ")"
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 "[ \t\n\r]*"
=A0=A0=A0=A0=A0=A0 "{&quo= t;
=A0=A0=A0=A0=A0=A0 )) 1))
=A0 "Imenu generic expression for Java mo= de.=A0 See `imenu-generic-expression'.")

I ended up just sp= litting out the annotations from the type from the identifier name to make = it easier in the argument list.=A0 A file that displays some of the matches= /non-matches is:

//(setq imenu-generic-expression cc-imenu-java-generic-expression)
<= br>public class Test {

=A0=A0=A0 void fun1() { }
=A0=A0=A0 void f= un2( int a ) { }
=A0=A0=A0 void fun3( int a, int b ) { }
=A0=A0=A0 Li= st<String > fun4() { }
=A0=A0=A0 Map< String,String > fun5() { }
=A0=A0=A0 void fun6( @No= nNull int a ) { }
=A0=A0=A0 void fun7( @NonNull int b, @NonNull int c ) = { }
=A0=A0=A0 void fun8( @NonNull List<String> a ) { }
=A0=A0= =A0 void fun9( @NonNull List<List<String >> a ) { }
=A0=A0=A0 void fun10( @NonNull int[] a) { }
=A0=A0=A0 void fun11( List&l= t; class.innerclass > foo ) { }
=A0=A0=A0 voif fun12( class.innerclas= s< Integer> foof ) { }

=A0=A0=A0 else if( a ) { }
=A0=A0=A0= else if( a < b ) { }
=A0=A0=A0 else if( a < b && b > a ) { }
=A0=A0=A0 else if(= =A0 a ) { }
=A0=A0=A0 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:
> OK. =A0I've not looked at it in all that great detail, = and haven't tried
> it out yet. =A0I'm not actually a Java hacker.
>
> How confident are you that your proposed regexp won't spuriously m= atch
> things with "less than" or "greater than" tokens? = =A0Or, 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,<= br> along the lines of etc/compilation.txt. =A0I don't know if you already<= br> have something like that; if so, we can put it in the new test/
directory.

(We should probably move etc/compilation into test/ also.)


--000e0cd2950a3acc5e04708e1bbe--