At 04:30 PM 11/30/99 +0000, you wrote:
>>>>>> "Rodrigo" == Rodrigo Reyes <[EMAIL PROTECTED]> writes:
>
> Rodrigo> When such a name is found, it calls the
> Rodrigo> jde.util.Completion class to get back all the possible
> Rodrigo> completion for this variable. Then, it builds a completion
> Rodrigo> list that can complete the "meth" method, or let every
> Rodrigo> possible choise, if the method is empty ("").
>
> Rodrigo> Of course, such a design _require_ to have the class
> Rodrigo> already compiled and added in the bsh classpath. I have
> Rodrigo> reasons to think that relying on the parser will give slow
> Rodrigo> and non-robust results. Another method is to used the TAGS
> Rodrigo> file, but, hey, there's nothing inside that's not easily
> Rodrigo> available through java introspection.
>
> Rodrigo> There are still many situation that are not handled by the
> Rodrigo> jde-complete.el, but I believe the most common cases are
> Rodrigo> handled OK.
>
>
> It seems to fail to identify the Type in the
>
> public void actionPerformed( ActionEvent event )
> {
> Object src = event.getSource();
> }
>
>
> situation, or at least it does in my case. A quick
>flick through the "parser" with edebug tends to suggest to me at least
>that this occurs because it identifies the type incorrectly. I havent
>tried this out throughly, so perhaps it was just my test case. If it
>works for you Ill come up with a good test case.
>
> I was wondering whether it would make sense to use
>the parser to parse the current file (which if I am not mistaken
>DOESNT need to be pre-compiled, only the type to be completed on!) to
>get the type information out? I have absolutely no experience with
>parsing, which is why I ask. Also there are a couple of things that I
>would quite like to develop, but which need variable to type matching
>(for instance the jump to help files command should really offer the
>type of the variable under point whilst at the moment it offers the
>variable name which is no use!). There are lots of other things for
>which syntactic information would be useful. Its a pity CC-mode stores
>syntatic information in the way it does, rather than the rather more
>accessible info provided by something like psgml mode. (I suspect C
>and Java is more complex to parse!).
I included the parser in the JDE for exactly this purpose. My intent was
and is to use it to permit completion of symbols defined in the current
source file but not yet compiled. The current grammar used by the parser is
not well-suited to this task because its top-level entity is a compilation
unit (the parser is basically a top-down parser). My plan is to modify the
grammar to start parsing at the statement or expression level and to
provide a lisp API for navigating the parse tree that results from parsing
statements and/or expressions. Once this is done it should be fairly
straightforward to complete on symbols defined (but not compiled) in the
current buffer. I believe performance should be acceptable, especially if
the parser vm is left running during a session. (This does raise the issue
of whether the JDE requires to many concurrently running vm's. Right now
it's possible to have three or more: the BeanShell vm, the debugger vm, and
one vm for each process being debugged.)
The JDE includes the complete source for the parser and the grammar. So
anybody who wants to work on this should feel free. Just let me know to
ensure that you are not dupicating somebody else's effort.
- Paul
