emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not


From: Alan Mackenzie
Subject: Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.
Date: Tue, 28 Jul 2009 10:19:59 +0000
User-agent: Mutt/1.5.9i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]