On Fri, 2002-06-28 at 19:43, Paul Kinnucan wrote:
> Jens Lautenbacher writes:
> > Hi, some time ago I posted a miniature patch to jde-devel (see attached
> > mail). Nobody reacted, but that may be just because nobody uses the
> > defun in question at all :-)
Hmm, did you look at the patch? Do you see any problems with it?
> > There seem to be quite some different defuns for jumping to source code
> > for various cases... some of those seem to do rather similar things. Is
> > there any plan to unify them into something that works "just right" (for
> > some to-be defined definition of "just right")??
> >
>
> 2.2.9beta10 tries to do exactly that:
> [list of commands callable from the menu ommitted]
No, I didn't mean to say that this list could be condensed into a
smaller set. What I mean is from the elisp side, it seems the
functionality is not aggregated into a set of general defuns.
I never got what should be the difference between
jde-open-source-for-symbol and jde-open-class-at-point (they _are_
behaving differently, but the intended goal of both seems to be the
same)
I was asking because I have a hard time telling which are the "right"
defuns to hack at when I want to implement a feature/fix a bug. But
maybe this is just because I have too little time to completely
understand that stuff.
>
> I am currently working on reimplementing the JDEE's name resolution
> and completion facilities to use semantic databases, e.g., parse data
> compiled by Emacs itself, and use Java reflection only as a backup,
> e.g., for resolving unqualified names when source is not available. I
> have already created a new utility package that makes the Java
> classpath, e.g., the reflection data in classes, look like semantic to
> clients, like the completion facility and code generation wizards.
> Thus the clients never need to know where the data is coming from,
> simplifying implementation.
This would be a very welcomed addition. Using the parse data from the
source leads to other problems, though.
How will the JDEE react, when I'm editing a buffer and it contains
errors? using the refection at least garantees that the code in question
has been compiled successfully. Will data that comes behind a "parse
errror" in a buffer become unavailable? Will I be able to complete on
changed classes before they have been compiled? This would be a very
nice feature, because when doing larger refactoring I occasionally
change some basic classes which leads to the project being in a
uncompilable state for a extended time.
Having the complete mechanism automatically catch up and use the current
definitions would come handy.
Speaking of refactoring, will it then be possible to e.g. change the
name of a method in a class and have all other occurances of this method
be changed, too?
Will it be possible to find not only a regexp in a java file, but also
e.g. every use of a variable of Type foo.bar.Baz (and correctly
discrimiate between variables defined as Baz in a source file that uses
"import foo.bar.*" and one that uses "import org.prj.Baz")?
many questions, I know :-)
Thanks,
jtl
