Re: Jde Xref problem
Maybe OT, but does anybody know what feature the normal jde-xref has that isn't done faster and without all the db stuff by the jde-usages plugin? While I really think jde-xref is cool, maybe we should think about integrating jde-usages itself... jtl signature.asc Description: This is a digitally signed message part
Re: Jde Xref problem
I think jde-usages is a perfectly acceptable replacement, and there is really no difference in functionality as far as I know. On Aug 18, 2004, at 4:08 AM, Jens Lautenbacher wrote: Maybe OT, but does anybody know what feature the normal jde-xref has that isn't done faster and without all the db stuff by the jde-usages plugin? While I really think jde-xref is cool, maybe we should think about integrating jde-usages itself... jtl
Re: Jde Xref problem
There are no missing pieces in jde-usages as far as I know too, but it does some things differently, based on my personal preference: 1) Instead of creating a new buffer each time you call one of the usage functions, jde-usages just reuses one buffer called *usages* 2) I did not implement the equivalent of jde-xref-first-caller and jde-xref-next-caller because I didn't use them. But there is a function which moves to the next usage line in the *usages* buffer and hits enter. I shall make the buffer name customizable and add functions to allow navigation between the usages without popping up the *usages* buffer. Also I find that having most of the code in java does not make for a pleasant experience while developing. I'm constantly restarting the bsh process to test new changes. I'm considering using beanshell functions instead of straight java code for parts of the project. Right now, I am, as time permits, working on two subprojects: 1) Using qdox (http://qdox.codehaus.org/) to parse files in jde-sourcepath so that the class hierarchy and class navigation functions don't require the source to be compiled to work. I really need this because compiling my entire project at work from scratch takes more than an hour and during that time JDE can't help me much because the class files are not yet available. 2) Allowing jde-usages to return the same kind of class info structures that jde.util.Completion does. Plusses for this: a) a smaller beanshell process size, since there would be just one component that looked at class files, b) Since jde-usages doesn't keep the files in the classpath open across invocations, on windows it would allow me to delete jar files in the classpath without shutting down the beanshell process. c) You wouldn't have to, in theory, call jde-complete-flush-classinfo-cache manually if you built your project from outside of emacs. This would come at the cost of each completion being slower because of the extra time spent checking if the files in the classpath have changed, but I'm thinking of ways to make this check less aggressive and still useful. Suraj On Wed, 18 Aug 2004 06:29:32 -0400, Andrew Hyatt [EMAIL PROTECTED] wrote: I think jde-usages is a perfectly acceptable replacement, and there is really no difference in functionality as far as I know. On Aug 18, 2004, at 4:08 AM, Jens Lautenbacher wrote: Maybe OT, but does anybody know what feature the normal jde-xref has that isn't done faster and without all the db stuff by the jde-usages plugin? While I really think jde-xref is cool, maybe we should think about integrating jde-usages itself... jtl
Jde Xref problem
When using the jde-xref feature, I have experienced a problem. Syndrome: After jde-xref-make-xref-db, I moved the cursor to a method in one of my classes ClassA and did a C-c C-v a, I got this in the mini-buffer: Wrong type argument: listp, com.x.x.ClassB The ClassB is the super class of ClassA. C-c C-v n works fine. I took a look at the code in jde-xref.el. I seems to me that the offending section is in this area: (defun jde-xref-next-caller () If there are items still on the caller stack, pop the first one off and show it (interactive) (if jde-xref-stack (if (listp (car jde-xref-stack)) (jde-xref-goto-caller (pop jde-xref-stack)) (jde-xref-goto-caller (pop (pop jde-xref-stack ;; skip over called classname (message No more calls))) So if jde-xref-stack is not a list, it still pop it anyway in the else block. I don't understand the code good enough to fix it. But I like the feature very much and hope someone can take a look at it, or help me a little me to understand this so that I can fix it. Regards, Ping
Re: Jde Xref problem
I submitted a patch to fix this... I believe it is in the latest beta of JDE (2.3.4beta5). Raul On Tue, 17 Aug 2004, Ping Liang wrote: When using the jde-xref feature, I have experienced a problem. Syndrome: After jde-xref-make-xref-db, I moved the cursor to a method in one of my classes ClassA and did a C-c C-v a, I got this in the mini-buffer: Wrong type argument: listp, com.x.x.ClassB The ClassB is the super class of ClassA. C-c C-v n works fine. I took a look at the code in jde-xref.el. I seems to me that the offending section is in this area: (defun jde-xref-next-caller () If there are items still on the caller stack, pop the first one off and show it (interactive) (if jde-xref-stack (if (listp (car jde-xref-stack)) (jde-xref-goto-caller (pop jde-xref-stack)) (jde-xref-goto-caller (pop (pop jde-xref-stack ;; skip over called classname (message No more calls))) So if jde-xref-stack is not a list, it still pop it anyway in the else block. I don't understand the code good enough to fix it. But I like the feature very much and hope someone can take a look at it, or help me a little me to understand this so that I can fix it. Regards, Ping
