Hi Javier, I just wanted to alert you and other JDEE users and contributors to some plans I have for jde-open-source and get your comments. First, the JDEE has now accumulated a number of commands that "jump" the user to the source of the class that defines the symbol at point in the current buffer. Some of these commands now live on the Help and Find menus. Others are not bound to any menus. I'd like to group these commands together and give them more visibility in the JDEE user interface. So my plan is to create a new JDEE toplevel menu called Goto that contains the following commands.
Goto Symbol Definition (formerly jde-open-source) Super class Interface The menu would appear below the JDEE's Find menu, which finds occurences of expressions. I plan to put all the JDEE's "goto" commands and supporting functions in a new jde-goto.el package. I have already created this package and include the jde-open-source commands in it. I plan to commit the new package to CVS shortly. After doing this, I plan to delete jde-open-source.el from CVS to avoid confusion. The new package renames jde-open-source as jde-goto-def. Regarding jde-goto-def, I appreciate the work that you have done to reduce its dependency on jde-complete. I'd like to take your work a step futher and eliminate any dependency. To do this, I plan to create a new Lisp package, named jde-ci, and a corresponding Java utility class, named jde.util.ClassInfo, devoted to using Java reflection to get information about a class. This class would incorporate and abstract the "class info" code in jde-complete.el and jde.util.Completion. This would allow us to eliminate jde-goto-def's dependency on jde-complete.el. Ultimately, I envision the Class Info package serving as a resource for both goto and completion commands and any other JDEE command that needs to get information about a particular class's field, methods, exceptions, etc. Finally, I do not think that jde-goto-def goes far enough in its present shape. Presently, it jumps the user to the first occurence in the source file of the symbol whose definition the user wants. This may or may not be the actual definition of the symbol of interest. The actual definition may be further down in the source file. The problem is that jde-goto-def knows only the name of the symbol of interest. To find its definition, jde-goto-def needs to determine the type and, in the case of methods, the signature of the symbol of interest. I'd like to see jde-goto-def enhanced to do this. Regards, Paul
