Re: [CEDET-devel] java semanticdb backend?

[Eric M. L. <er...@si...>]

>>> "Suraj Acharya" <sac...@cs...> seems to think that:
>Hi Eric,
>
>Thanks for very detailed reply :-) Some sort of unified eldoc and completion
>with inputs from both CEDET as well as JDE would indeed be very useful. I
>started to look at semantic-complete.el but soon got lost, so here are some
>really basic questions:

There are a few independent layers to try and understand.

At the bottom is a parser generator, and some parsers that produce a
list of tags for a particular buffer.

Those tag lists are also associated with a database table.
Tables are stored in a particular database which is associated with a
particular directory and a save file.

Some databases generate tags from other sources (like beanshell, if
implemented.)  As such, these DBs can look just like regular semantic
parsed files, just faster.

---

ok, that's tag management.  Then there is searching.

---

semantic-find searches through a tag list for some match by name,
return type, class (function, variable) or whatever.

semanticdb-find searches through lists of databases for the same.  You
can either search through all known databases vaguely related to a
project, or through a selective subset based on a recursive search of
#include/import statements.

---

That's searching.  For completion:

---

semantic-ctxt.el has a few tricks for parsing source code around a
point to determine what a completion prefix might be.

senator.el is a minor mode, and some if it's features include simple
brute force completion, and other features.

semantic-analyze.el has the analysis tools that convert a prefix (like
a.b.c) into a list of matching tags, analyzes the local context to
determine what the type needed is (1st arg of a fcn, assign into a
variable, etc.)

semantic-complete.el is a rather complex system for managing
completions from a system where providing "every" tag you might want
is unwise.  It has a lot of other crazy features specific to assisting
a user narrow down a tag list.  It uses several methods for generating
completion lists and for assisting in choosing a tag by name, such as
tooltips of completion lists, or showing where a tag is defined in a
different window so you can see what you are completing.

semantic-ia.el  has some simple completion routines using
semantic-analyze to choose completions.  It is basically demos of
using semantic-analyze.el

semantic-idle.el has fancy eldoc and auto-completion features.

semantic-sb.el puts various features of semantic and the analyzer into
speedbar.

There, hopefully my other answers can be short. ;)

>1) How would I use semanticdb to find all the methods in class "
>some.package.ClassName"?

If `semantic-dependency-tag-file' doesn't resolve your import of
some.package.Classname into a particular java file, you would need to
override that function for java.  At this point, semanticdb-find would
add it to a list of tables.   If that table/file can't be found, then
we would rely on the as yet unwritten beanshell to eventually get a
tag representation of some.package.Classname.

>My (false) impression has been that semanticdb was designed to only answer
>questions like "what are all the methods with names starting with 'foo'".
>I'm sure there is a smart way to restrict your search using an appropriate
>tag table, but I can't figure out where the code mapping from a java
>namespace to a tag table would go.

semantic-analyze.el with the help of semantic-ctxt.el will find all
C++ 'using' type statements, and add those to various search lists
till the desired symbol is found.  I'm not that familiar with Java,
but you will likely need to override `semantic-ctxt-scoped-types' to
get that list.

>2) Does semantic-complete do some analysis of the tokens before the string
>being completed to figure out what tag table to use?
>For example, if I've trying complete the following line in a java-mode
>buffer:
>
>a.b.c.foo

It is semantic-ctxt.el's job to convert a.b.c.foo into a prefix, and
determine basic state around that statement.

semantic-analyze.el's job to resolve the prefix.  First it will try to
find 'a' in all included scopes.  (See above.)  In a, it will try to
find b, in b, it will try to find c, and in c, it will do a completion
search for 'foo' to see what turns up.

Lastly, for all possible 'foo' matches, it looks to see what the
return value of foo will be used for, and extrapolates the type
needed.  It then narrows down the list of 'foo's to only those that
return a particular type.

Thus:

  int q;

  q = a.b.c.foo-!-

Or:

  blah(int a, char b);

  blah(a.b.c.foo-!-

it will find a foo of type int and provide only that, or those if
there is more than one.

>Then this should show me tags with names starting with "foo" which are
>children of the java class that "c" is an instance of.
>In the JDEE we have some very nasty looking code which analyzes an
>expression like "a.b.c" and tries to guess what its type is. Is there a
>mechanism to hook mode specific completion logic into semantic-complete?

This system in semantic complex, but I think it is relatively well
organized.  The main problems it has is determining all available
scopes in a language independent way, and also making sure the correct
databases are searched.

Key reasons this stuff doesn't work in java are:

* Missing overloads for items that are distinctly not C++
* Missing global database for all those library calls.

Hope that helps.  I think the barrier to entry on Java successfully
using this stuff is relatively small since it is quite similar to C++
in some ways.

Eric

>Suraj
>
>On 2/15/07, Eric M. Ludlam <er...@si...> wrote:
>>
>> >>> "Suraj Acharya" <sac...@gm...> seems to think that:
>> >Forgive me for not RTFM, but what will having a java semantic db back-end
>> >give us? I maintain the jde-usages plugin for JDE (jde-usages.sf.net) and
>> >might be able to help.
>>
>> Summary:
>>
>>    Supporting JDE core functionality (beanshell searching) in Semantic
>>    allows JDE tools and UIs to be ported to Semantic, and used in
>>    other languages.
>

-- 
          Eric Ludlam:                 za...@gn..., er...@si...
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org