Hi,
I can answer some of the higher level questions.
>>> Stuart Popejoy <stuart@...> seems to think that:
>I wanted to report to the mailing list shortcomings i've found with
>semantic with regards to context, analysis and completion of java code.
>
>Below is annotated java code that shows where the problems/issues occur.
>The problems in summary are:
>
>a. semantic-get-local-variables and semantic-get-all-local-variables do
>not work outside of method blocks. They should, as field declaration
>statements can access previously-declared fields; and static blocks are
>executable code, so it should work there too. (see comments 1, 2, 15)
The local variables function is meant to only return variables
declared inside the body of a method. This is because method bodies
are not parsed by semantic parsers, so this extra routine is needed.
To get all variables accessible to a point inside a method, you need
to do some stacked-scoped searches. The semantic-analyze package
needs to do something similar, but never generates this list.
Instead it performs some customized searches which are similar.
To get the list, you can do this:
(nreverse (semantic-find-nonterminal-by-overlay (point)))
You now have a list, where the (car ..) is the smallest (in size)
token. (ie, the method you are in.)
For each token, use (semantic-nonterminal-children ...) to get the
list of children. These children will be (I assume) in scope of
(point).
You can now use search routines to get just the variables (fields)
(semantic-find-nonterminal-by-token 'variable (semantic-nonterminal-children ...) nil nil)
This type of routine sounds like something useful we could add.
>b. semantic-current-nonterminal does not handle classes declared within
>methods properly, always returning the outer method, instead of the
>inner/anonymous class or it's methods (comments 5, 6, 8, 11, 13, 17)
Yes, this is because method bodies are never parsed. The
get-local-variables function also is not very smart. It will only
find variables declared before any normal code segments.
I wrote it originally for C code, so naturally this was good enough.
Fortunately, get-local-variables is an override method, so it could
be extended.
My assumption, longer term, is that languages written in wisent will
have full parsers, that could be used to parse out method bodies on
demand. Even so, `semantic-current-nonterminal' will not see these
inner declarations.
Even now, David Ponce had written a java parser that parses
everything. Since we are still working on basic infrastructure, I
haven't had time to think about these types of extensions, and how
they would work.
>c. perhaps semantic-current-nonterminal should return something to
>indicate a static block (comment 3)
David can answer this better than I, but in Emacs Lisp, code can
exist free-floating, and I labeled these as code blocks.
One trick you can use, if you aren't sure how things are being
treated, is to use `semantic-show-unmatched-syntax-mode' to quickly
see what semantic does or does not understand.
>d. semantic-get-local-variables returns variables that haven't been
>declared yet (comments 4, 7, 9, 12, 14, 16)
I don't know what that means, but again, get-local-variables is
pretty simple, as I described above.
Also, get-local-variables will refuse to do anything unless it is
inside a 'function token (a method in java).
>e. variables declared in a for statement are not included in
>semantic-get-local-variables (comment 5)
>
>f. semantic-end-of-command does not handle anonymous class declaration
>statements properly (comment 10).
The default functionality of all routines in the -ctxt file were
written for C code (and sometimes C++) as override methods. New
implementations would need to be written for java to overcome
divergence between the structure of the two languages.
This routine limits searching to within the nearest set of {} braces,
and looks for ;. Not too complex
Much of your concern seems to be around a misinterpretation of what
`semantic-get-local-variables' can do. I briefly described above how
to get some of the list you desire. Getting variables declared in a
for(...) statement done right will probably require yet more
infrastructure work targeted at parsing method bodies.
Method body parsing is not currently done, and I recommend against it
in general as a major time sink in the overall time spent parsing for
something rarely used. (ie, if you never scroll to the bottom half
of a file, why parse those method bodies?)
Method body parsing IS useful in these situations:
1) completion/suggestion type code.
2) underline "interesting stuff" like syntax errors or bad references.
Both these conditions can be done "on demand" instead of at global
parse time, and end up as secondary importance to much of the
infrastructure work we are currently doing.
Hopefully we can work out solutions to your problems. It may be some
elements cannot be handled until the details of method body parsing,
when it happens, and what happens to the data is worked out. Since
David is the only one to have written something that can parse method
bodies (in Java no less), I'll be relying on him to help shed some
light on the timing issues.
These are some great questions. Thanks for looking into these things
so thoroughly.
Eric
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org