Jens Lautenbacher writes: > 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? >
I just looked at it. Your change makes sense. However, jde-open-class-at-point supercedes jde-open-source-for-symbol (see below). > > 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) jde-open-source-for-symbol and jde-open-class-at-point are contributed commands contributed at different times by different authors working independently. jde-open-source-for-symbol was contributed first and was intended ultimately to have the functionality of jde-open-class-at-point. I intended to remove jde-open-source-for-symbol as soon as jde-open-class-at-point proved itself in beta testing. jde-open-class-at-point only became available in beta10. > > 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? Probably. > Will I be able to complete on > changed classes before they have been compiled? \ Yes. > 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. > That's the primary motive for making this change. > 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? > In theory, yes. In fact, this is possible now for compiled classes. But refactoring requires that someone write the code to do the refactoring. > 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")? > Yes, given someone willing to write the necessary Lisp. - Paul
