Re: Compiler window deletion - UI question/suggestion
On Wed, 2005-04-06 at 14:24 -0700, Jeff Peck wrote: If everyone else only expects one window per frame, and really wants to close the second/temporary compile output window, then maybe we should make creative use of save-window-excursion, to restore the configuration? That's what I do. Starting a compilation saves the window configuration, and in the hook when the compilation is done, I restore it. I need to tweak it so it doesn't restore the window configuration if I've switched buffers around too much, but the idea is the same. Raul
RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ...
I'm sure you mean sourceforget.net right? :) On Fri, 2004-12-17 at 19:30 +, Matthew Kurjanowicz wrote: It may also be nice (if its possible/allowed) to mirror this in a project at slashdot. I like sunsite.dk and am very appreciative, but if they don't want to host multiple versions then slashdot would do that (as well as keeping track of every release and when it was made). I'm not saying move the whole project to slashdot, just mirror the releases there. $0.02, -Matt Actually, it would be nice if the download file were called jde-2.3.5.zip instead of always being jde-latest.zip. It makes it easier to track versions I have downloaded and installed. Raul On Fri, 2004-12-17 at 12:56 -0500, Paul Kinnucan wrote: Britton, Chris writes: Hi Paul. I'm still getting JDE 2.3.4 from jde-latest.zip at this location. Can you please confirm if jde-latest.zip contains 2.3.5? Hi Chris, I just downloaded jde-latest.zip and verified that it contains 2.3.5. It seems that at least one person has this problem shortly after every release. Apparently, there's some kind of caching of download files going on somewhere. I'm posting this reply to the JDEE mailing list as well as to Chris in the hopes that somebody who is more knowledgable about the Internet than I am can explain this phenomenon and suggest a solution to keep it from happening or recovering from it if it does happen. Regards, Paul Thanks. -- Chris Britton [EMAIL PROTECTED] -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Friday, December 17, 2004 8:07 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] JDEE 2.3.5 available at ... http://jdee.sunsite.dk/rootpage.html#Downloading JDE 2.3.5 *** * PLEASE READ * *** * * * This release requires cedet 1.0beta2 or later. cedet* * includes semantic, eieio, speedbar, and senator, all* * packages required by the JDEE. You can obtain cedet * * at http://cedet.sourceforge.net * * * * Please note that your .emacs file must load cedet.el, * * not require cedet. See the installation instructions * * that come with the cedet package for more information. * * * * This release requires version 1.2.2 (or later) of the * * JDK.* * * * This release also requires avltree.el, which is part of the * * elib 1.0 package. You can obtain elib at the JDE web site * * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz) * * or zip (http://sunsite.dk/jde/elib.zip) format. * * * * JDEbug runs on Windows 2000 only if Service Pack 2 (or * * later) is installed.* * * * If syntax-coloring does not work, download and install * * overlay-fix.el from the semantic web site. * * * *** * On XEmacs, Use efc-xemacs-query-options, i.e., a GUI dialog box instead of a text dialog box, only if use-dialog-box is nonnil. * Fixes bug in ProjectClasses to avoid duplicate entries of imports. * Updated JDEE's Ant interface to force use of pipes to interact with external Ant process. * Fixed regression that caused jde-help-class-member to issue a Lisp error. * Fixed regression in jde-wiz-update-class-list command. * Fixed regression that caused JDEbug to issue a Lisp error when launching an application. Thanks to Martin Schwamberger. * Revise the following templates to conform to CheckStyle requirements: - jde-gen-deep-clone-template - jde-gen-to-string-method-template - jde-gen-bean-template Thanks to Martin Schwamberger. * Added the following code generation templates: - jde-gen-exception Generates an exception class in the current buffer. - jde-gen-exception-buffer Generates a buffer containing an exception class. - jde-gen-hashcode-method Generates a hashcode method at point. -
RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ...
In the face of world hunger, poverty, and a Republican administration, it is a small issue I can live with. :) On Fri, 2004-12-17 at 18:18 -0500, Latchezar Dimitrov wrote: Is it too big a problem for you to rename it the way you like most after d/l? Thanks, Latchezar -Original Message- From: Raul Acevedo [mailto:[EMAIL PROTECTED] Sent: Friday, December 17, 2004 2:24 PM To: Paul Kinnucan Cc: Britton, Chris; [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ... Actually, it would be nice if the download file were called jde-2.3.5.zip instead of always being jde-latest.zip. It makes it easier to track versions I have downloaded and installed. Raul On Fri, 2004-12-17 at 12:56 -0500, Paul Kinnucan wrote: Britton, Chris writes: Hi Paul. I'm still getting JDE 2.3.4 from jde-latest.zip at this location. Can you please confirm if jde-latest.zip contains 2.3.5? Hi Chris, I just downloaded jde-latest.zip and verified that it contains 2.3.5. It seems that at least one person has this problem shortly after every release. Apparently, there's some kind of caching of download files going on somewhere. I'm posting this reply to the JDEE mailing list as well as to Chris in the hopes that somebody who is more knowledgable about the Internet than I am can explain this phenomenon and suggest a solution to keep it from happening or recovering from it if it does happen. Regards, Paul Thanks. -- Chris Britton [EMAIL PROTECTED] -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Friday, December 17, 2004 8:07 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] JDEE 2.3.5 available at ... http://jdee.sunsite.dk/rootpage.html#Downloading JDE 2.3.5 *** * PLEASE READ * *** * * * This release requires cedet 1.0beta2 or later. cedet* * includes semantic, eieio, speedbar, and senator, all* * packages required by the JDEE. You can obtain cedet * * at http://cedet.sourceforge.net * * * * Please note that your .emacs file must load cedet.el, * * not require cedet. See the installation instructions * * that come with the cedet package for more information. * * * * This release requires version 1.2.2 (or later) of the * * JDK.* * * * This release also requires avltree.el, which is part of the * * elib 1.0 package. You can obtain elib at the JDE web site * * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz) * * or zip (http://sunsite.dk/jde/elib.zip) format. * * * * JDEbug runs on Windows 2000 only if Service Pack 2 (or * * later) is installed.* * * * If syntax-coloring does not work, download and install * * overlay-fix.el from the semantic web site. * * * *** * On XEmacs, Use efc-xemacs-query-options, i.e., a GUI dialog box instead of a text dialog box, only if use-dialog-box is nonnil. * Fixes bug in ProjectClasses to avoid duplicate entries of imports. * Updated JDEE's Ant interface to force use of pipes to interact with external Ant process. * Fixed regression that caused jde-help-class-member to issue a Lisp error. * Fixed regression in jde-wiz-update-class-list command. * Fixed regression that caused JDEbug to issue a Lisp error when launching an application. Thanks to Martin Schwamberger. * Revise the following templates to conform to CheckStyle requirements: - jde-gen-deep-clone-template - jde-gen-to-string-method-template - jde-gen-bean-template Thanks to Martin Schwamberger. * Added the following code generation templates: - jde-gen-exception Generates an exception class in the current buffer. - jde-gen-exception
Re: Java Buffer modified on reading
I don't know when this started happening, but I have noticed that loading any Java buffer creates lots of Wrong type argument: integer-or-marker-p, nil errors in the *Messages* buffer. While that doesn't halt loading of the buffer for me (which is what leaves the buffer marked modified), I believe the problem is the buffer fontification. Raul On Mon, 2004-11-22 at 12:40 -0500, Roland Roberts wrote: -BEGIN PGP SIGNED MESSAGE- When I edit an existing java file, my *Messages* buffer reads Setting customized JDE variables to startup values... Fontifying Time_Rule_Type.java... (regexps..) Setting customized JDE variables to startup values... eval: Wrong type argument: integer-or-marker-p, nil [2 times] Building Security.java Semantic directory index imenu [2 times] and the buffer is marked modified. I've tried moving aside my .custom.el but the problem is not there. I've compared my .emacs with that on another host where this does not happen and, if the problem is there, it would take considerable work to narrow it down due to the unrelated stuff that loads. What *is* different between the two is the version of JDEE. The one with the problem is the latest download which is 2.3.4, The one on the host without the problem is older, but I can't find a version number; the last ChangeLog entry is 2003-12-08 Paul Kinnucan [EMAIL PROTECTED] * jde-util.el: Update jde-find-class-source to work for inner classes. This is on GNU Emacs 21.3, and I do have the overlay-fix.el loaded, but the problem does not seem to be affected by that, either. Any tips on making this go away? - -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises [EMAIL PROTECTED]6818 Madeline Court [EMAIL PROTECTED] Brooklyn, NY 11220 -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.5.8, an Emacs/PGP interface iQCVAwUBQaIkdeoW38lmvDvNAQHZHgQAvA+tNXlL3mqHPoU/wEtwtmZ1AEkARaaz 0/7+WrodGUyNFHtRDtFnEU6tP2vntKlAehJGm1f1Jds6oP39W4zKU2O1NHcajKOK GvGewHNTVBVPyFUjIlboCxZoHkfDf0Hu/wc9lkzmQB0LqDfuKHmx2eWHRFn6gCRh FW0HjuJbw2k= =9HVR -END PGP SIGNATURE-
jde and emacs memory usage
Right now my Emacs process is using 127 Megs of memory. While the *jde-beanshell-scratch* buffer size is 1239491, and another buffer I have is also just over 1 Meg, the total sum of all my buffers is still only a few megabytes, I definitely am not consuming anywhere near 100 megabytes in buffers. What could be taking up all the memory? How do I free it up? I've had emacs run out of memory a few times in the last couple of weeks. Raul
Re: jde and emacs memory usage
That's cool... but it's still only about one megabyte. I still have close to 100 megabytes of unexplained memory somewhere... any thoughts? Raul On Thu, 2004-11-18 at 13:15 -0800, Suraj Acharya wrote: The jde-beanshell-buffer is something that jde-usages to record the output of bsh. It's like a *Messages* buffer for the beanshell, but unlike *Messages* it doesn't clear out old entries. Adding the equivalent of message-log-size for this buffer is on my to-do list. You can delete the buffer at any point without any adverse effects. The next time jde-usages makes a call to bsh it will create the buffer if it does not exist. Suraj On Thu, 18 Nov 2004 11:53:11 -0800, Raul Acevedo [EMAIL PROTECTED] wrote: Right now my Emacs process is using 127 Megs of memory. While the *jde-beanshell-scratch* buffer size is 1239491, and another buffer I have is also just over 1 Meg, the total sum of all my buffers is still only a few megabytes, I definitely am not consuming anywhere near 100 megabytes in buffers. What could be taking up all the memory? How do I free it up? I've had emacs run out of memory a few times in the last couple of weeks. Raul
Re: [jde] [ANNOUNCEMENT] JDEE 2.3.4beta6 available at ...
Sounds fantastic, Paul. Thank you!!! Raul On Wed, 2004-10-13 at 01:14 -0400, Paul Kinnucan wrote: http://jdee.sunsite.dk/rootpage.html#Downloading JDE 2.3.4beta6 *** * PLEASE READ * *** * * * This release requires cedet 1.0beta2 or later. cedet* * includes semantic, eieio, speedbar, and senator, all* * packages required by the JDEE. You can obtain cedet * * at http://cedet.sourceforge.net * * * * Please note that your .emacs file must load cedet.el, * * not require cedet. See the installation instructions * * that come with the cedet package for more information. * * * * This release requires version 1.2.2 (or later) of the * * JDK.* * * * This release also requires avltree.el, which is part of the * * elib 1.0 package. You can obtain elib at the JDE web site * * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz) * * or zip (http://sunsite.dk/jde/elib.zip) format. * * * * JDEbug runs on Windows 2000 only if Service Pack 2 (or * * later) is installed.* * * * If syntax-coloring does not work, download and install * * overlay-fix.el from the semantic web site. * * * *** * Moved JUnit templates to a separate package jde-junit.el and added some contributed commands for starting unit tests. This restructuring is preparatory to providing more systematic support for unit testing in the JDEE in future releases. * Configured the JDEE to always use pipes (rather than pseudo terminals) to communicate with external processes (see process-connection-type for more info). This change assumes that Java processes expect to use pipes. This change fixes a Code 129 error with XEmacs on some Linux operating systems and may fix similar errors on Linux with Emacs. * Fixed Emacs interface to JDEbug so that it handles chunked responses to debugger commands. Thanks to Brian Rumple. * If jde-run-application-class is a jar file, expand any environment variables or relative path indicators in the jar file path. Thanks to Joshua Spiewak. * The JDEE now supports use of emacs-w3m to browse Javadoc files. To use emacs-w3m, set jde-help-browser-function to w3m-browse-url. * Fixes bug that caused the generation of an extraneous slash in Javadoc URLs on UNIX systems. * Adds an Import submenu to the Code Generation menu. The submenu contains all of the JDEE's import-related commands. * JDEE now allows the plugins directory to be under CVS or RCS version control, i.e., to contain a directory named CVS or RCS. * Fixes regressions that broke applet debugging. * Upgrades BeanShell from version 1.2.7 to version 2.0b2. * Update the class list used by completion and by code generation wizards after compiling a class or building a project. This should ensure that completion and the wizards work for new classes and changes to existing classes after compiling new or changed classes. * This release includes the following enhancements to the JDEE's class import wizard. - A new customization variable: jde-import-excluded-classes. The new variable replaces jde-import-excluded-packages, which the JDEE no longer defines. The new variable provides the following new class exclusion options. - It allows you to use Lisp functions as well as regular expressions to specify exclusion rules. - It allows you to specify that a rule excludes all unqualified synonyms of a class that meets the rule. For example, one of the default rules specifed by this variable excludes java.lang.String as well as any other class whose unqualified name is String. - This release adds the jde-import-expand-imports command. This command replaces package imports, e.g., java.io.* with imports of the classes specifically referenced by the current buffer. - The following commands now include a prefix argument that causes all classes to be imported, regardless of the setting of jde-import-excluded-classes. - jde-import-find-and-import - jde-import-all-filter
Re: [jde] [ANNOUNCEMENT] JDEE 2.3.4beta6 available at ...
The tar file download has permissions of [76]00 for all files and directories, meaning only root can access them (if you untar/install as root). I had to chmod everything to make it world readable. Raul On Wed, 2004-10-13 at 01:14 -0400, Paul Kinnucan wrote: http://jdee.sunsite.dk/rootpage.html#Downloading JDE 2.3.4beta6 *** * PLEASE READ * *** * * * This release requires cedet 1.0beta2 or later. cedet* * includes semantic, eieio, speedbar, and senator, all* * packages required by the JDEE. You can obtain cedet * * at http://cedet.sourceforge.net * * * * Please note that your .emacs file must load cedet.el, * * not require cedet. See the installation instructions * * that come with the cedet package for more information. * * * * This release requires version 1.2.2 (or later) of the * * JDK.* * * * This release also requires avltree.el, which is part of the * * elib 1.0 package. You can obtain elib at the JDE web site * * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz) * * or zip (http://sunsite.dk/jde/elib.zip) format. * * * * JDEbug runs on Windows 2000 only if Service Pack 2 (or * * later) is installed.* * * * If syntax-coloring does not work, download and install * * overlay-fix.el from the semantic web site. * * * *** * Moved JUnit templates to a separate package jde-junit.el and added some contributed commands for starting unit tests. This restructuring is preparatory to providing more systematic support for unit testing in the JDEE in future releases. * Configured the JDEE to always use pipes (rather than pseudo terminals) to communicate with external processes (see process-connection-type for more info). This change assumes that Java processes expect to use pipes. This change fixes a Code 129 error with XEmacs on some Linux operating systems and may fix similar errors on Linux with Emacs. * Fixed Emacs interface to JDEbug so that it handles chunked responses to debugger commands. Thanks to Brian Rumple. * If jde-run-application-class is a jar file, expand any environment variables or relative path indicators in the jar file path. Thanks to Joshua Spiewak. * The JDEE now supports use of emacs-w3m to browse Javadoc files. To use emacs-w3m, set jde-help-browser-function to w3m-browse-url. * Fixes bug that caused the generation of an extraneous slash in Javadoc URLs on UNIX systems. * Adds an Import submenu to the Code Generation menu. The submenu contains all of the JDEE's import-related commands. * JDEE now allows the plugins directory to be under CVS or RCS version control, i.e., to contain a directory named CVS or RCS. * Fixes regressions that broke applet debugging. * Upgrades BeanShell from version 1.2.7 to version 2.0b2. * Update the class list used by completion and by code generation wizards after compiling a class or building a project. This should ensure that completion and the wizards work for new classes and changes to existing classes after compiling new or changed classes. * This release includes the following enhancements to the JDEE's class import wizard. - A new customization variable: jde-import-excluded-classes. The new variable replaces jde-import-excluded-packages, which the JDEE no longer defines. The new variable provides the following new class exclusion options. - It allows you to use Lisp functions as well as regular expressions to specify exclusion rules. - It allows you to specify that a rule excludes all unqualified synonyms of a class that meets the rule. For example, one of the default rules specifed by this variable excludes java.lang.String as well as any other class whose unqualified name is String. - This release adds the jde-import-expand-imports command. This command replaces package imports, e.g., java.io.* with imports of the classes specifically referenced by the current buffer. - The following commands now include a prefix argument that
Re: [jde] jde-usages and jde-2.3.4beta6 do not play nicely together
Same problems if process-connection-type is t. (I did note that it's used in a macro and rebuilt all the .elc files before trying.) Raul On Wed, 2004-10-13 at 15:14 -0400, Paul Kinnucan wrote: Raul Acevedo writes: The jde-usages plugin doesn't like the new JDEE beta 6. It's hard to describe the behavior, but they clearly don't work together. The jde-usages commands don't work well or at all, and after running them, the JDEE keeps restarting the bsh process. I'm on Linux, Fedora Core 2. Is this possibly a process-connection-type issue? Possibly. You could easily test this by changing the setting of process-connection-type from nil to t in jde-run.el Paul
Re: [jde] Re: [jde] problems finding symbol definition if class implements interface
On Sat, 2004-10-09 at 00:32 -0400, Paul Kinnucan wrote:
Raul Acevedo writes:
Looking at the JDEE source, it looks like it just doesn't know about
symbols in interfaces at all. In particular, jde-open-jump-to-class
only knows to look in the parent class, but it doesn't consider any
implemented interfaces, either in the current class or in any parent
class. Is this a known limitation?
Not to me. jde-open-jump-to-class has other limitations as well. I
plan to work on removing them as soon as possible. If anybody else
wants to jump in and help with this, feel free.
Here's an implementation that looks through all interfaces in addition
to the parent classes. It keeps a list of already seen classes lest we
get into an infinite loop somehow. It also restores buffer positions
after it visits a buffer and doesn't find what it wants, and does a
bury-buffer on all intermediate buffers visited so if the definition you
want is in another buffer, and you do Ctrl-x b, your previous buffer is
right there (instead of the default now being some random file you
haven't explicitly visited).
This method is somewhat complicated so I'm sure I haven't done it the
best way and haven't taken everything into account, but it Works For Me.
Ideally though this would be done entirely differently... rather than
visiting a bunch of files, maybe there's a way to use the jde-usages
plugin data to find the definition directly and more efficiently.
Raul
(defun jde-open-jump-to-class (parsed-symbol class-name java-file-name)
Opens JAVA-FILE-NAME and place the cursor in the parsed variable
(let* (tokens super-class seen-before old-point (first-time t))
;; if the current buffer contains java-file-name do not try to
;; open the file
(if (not (string-equal (buffer-file-name) java-file-name))
(funcall (or jde-open-cap-ff-function-temp-override
jde-open-class-at-point-find-file-function)
java-file-name))
(setq old-point (point))
(search-forward { nil t)
(setq tokens (append (semantic-tag-type-superclasses
(semantic-current-tag-of-class 'type))
(semantic-tag-type-interfaces (semantic-current-tag-of-class
'type
(setq super-class (car tokens))
(when (and (fboundp 'senator-search-forward) (not (string= parsed-symbol )))
(beginning-of-buffer)
(senator-parse)
(setq parsed-symbol (concat \\b parsed-symbol \\b))
(while (and (not (senator-re-search-forward parsed-symbol nil t))
(consp tokens))
(message (format tokens %s tokens))
(let ((token (car tokens)))
(setq tokens (cdr tokens))
(if (and (stringp token)
(not (member token seen-before)))
;; searching for the thing-of-interest has failed
;; let's try in the base class
(progn
(setq seen-before (cons token seen-before))
(goto-char old-point)
(if (not first-time) (bury-buffer))
(let ((jde-open-cap-ff-function-temp-override 'find-file))
(jde-show-superclass-source-2 (ncons token)))
(setq old-point (point))
(beginning-of-buffer)
(senator-parse)
(search-forward { nil t)
(setq tokens (append tokens
(semantic-tag-type-superclasses
(semantic-current-tag-of-class 'type))
(semantic-tag-type-interfaces
(semantic-current-tag-of-class 'type
;;if it is the first time try in the class definition
;;itself.
(if first-time
(progn
(setq first-time nil)
(senator-re-search-forward
(progn
(string-match .*\\.\\([^.]+\\)$ (concat . class-name))
(match-string 1 (concat . class-name)))
nil t)))
(if (not super-class)
(error Method not found))
(setq super-class token
Re: [jde] problems finding symbol definition if class implements interface
Looking at the JDEE source, it looks like it just doesn't know about
symbols in interfaces at all. In particular, jde-open-jump-to-class
only knows to look in the parent class, but it doesn't consider any
implemented interfaces, either in the current class or in any parent
class. Is this a known limitation?
Raul
On Thu, 2004-10-07 at 15:49 -0700, Raul Acevedo wrote:
I have something like:
public interface FooInterface {
public static final int FOO = 1;
}
public class FooClass implements FooInterface {
public void doSomething() {
System.out.println(I'm doing something with + FOO);
}
}
If I put the cursor on the System.out.println, on FOO,
jde-open-class-at-point can't find the definition. If I write
FooInterface.FOO instead of FOO, it's fine, but FOO by itself is not.
Raul
problems finding symbol definition if class implements interface
I have something like:
public interface FooInterface {
public static final int FOO = 1;
}
public class FooClass implements FooInterface {
public void doSomething() {
System.out.println(I'm doing something with + FOO);
}
}
If I put the cursor on the System.out.println, on FOO,
jde-open-class-at-point can't find the definition. If I write
FooInterface.FOO instead of FOO, it's fine, but FOO by itself is not.
Raul
Re: debugging with jdb
Would the problem be solved if comint returned code 1, instead of 129? In other words, is the problem that comint returns an inappropriate error code, or that comint returns *any* error code at all (i.e. it shouldn't get an error from the subprocess in the first place)? Raul On Fri, 2004-10-08 at 12:32 +1300, Len Trigg wrote: Paul Kinnucan wrote: No this is a problem with Comint on some combinations of Emacs and the host operating system. I believe it may have something to do with how comint handles standard error input from an external process, e.g., jdb. Yes, I think that's it too. I experience it and posted this bug report/test case to the XEmacs people: http://list-archive.xemacs.org/xemacs-beta/200408/msg00029.html (not that anything further has been done about it) Cheers, Len
debugging with jdb
I haven't debugged with JDE in a while, so I don't know if this is a new bug with the latest JDEE beta. Every time I display an expression with jdb, the debugger exits. Is this a known issue? It will display the expression just fine, and then exit with Comint exited abnormally with code 129. Should I use JDEBug instead? I remember there being issues a while back with using JDEBug, have those been resolved? Raul
Re: debugging with jdb
On Tue, 2004-10-05 at 15:18 -0400, Paul Kinnucan wrote: No this is a problem with Comint on some combinations of Emacs and the host operating system. I believe it may have something to do with how comint handles standard error input from an external process, e.g., jdb. It's my impression that recent versions of Emacs or Linux have developed an incompatibility in this area. I cannot fix this problem without the active assistance of those who are experiencing it as I do not experience the problem on the versions of Emacs, Windows XP, and Linux that I use. I'm willing to help you figure that out... I just tried JDEBug, and that also doesn't work. The JDEBug process dies mysteriously shortly after I try to attach to a local process, with no error message on the Emacs side. However the stdout for the Java process I'm connecting to says Transport error, error code = -1. I'm using JDK 1.4.2_05 on Linux. Do you know anything about that? Raul
Re: refactoring in jdee
On Thu, 2004-09-30 at 13:50 -0400, Paul Kinnucan wrote: My plan originally was to use xref as a basis for factoring commands. Now it appears that jde-usages might be a better basis. I need input on what kind of factoring commands users want. I think just being able to refactor variable and method name changes would be awesome. Raul
Re: [jde] Re: refactoring in jdee
On Thu, 2004-09-30 at 13:58 -0400, Matt Kurjanowicz wrote: The ability to change class names as well would be awesome :) Yes, that would be cool also. In terms of priority, I'd rather see variable and method refactoring first, since that's a bit more common. With jde-usages in place, adding this to JDEE would be one of the last major steps towards it being as full featured as commercial IDEs. :) Raul
Re: refactoring in jdee
On Thu, 2004-09-30 at 12:01 -0600, m0smith wrote: Also, extracting a method woutld be very useful. Good lord that sounds like dental work. :) What exactly is method extraction? Raul
how to get semantic to shut up
How do I get semantic to shut up? It has a really, really annoying habit of constantly filling the minibuffer with annoying messages like incremental parser error and Variables: foo bar and who knows what other nonsense. I really couldn't care less. Is there some global setting to tell it to keep quiet and do its job? Raul
refactoring in jdee
I know this question comes up at least once a year. I figure it's about time to ask again, in case new tools have come up. How do you do refactoring in Emacs/JDEE? Are there plans to include refactoring into JDEE at some point? Raul
Re: how to get semantic to shut up
Thanks! On Wed, 2004-09-29 at 20:46 +, [EMAIL PROTECTED] wrote: On Wed, 29 Sep 2004 13:39:54 -0700, Raul Acevedo wrote: How do I get semantic to shut up? It has a really, really annoying habit of constantly filling the minibuffer with annoying messages like incremental parser error and Variables: foo bar and who knows what other nonsense. I really couldn't care less. Is there some global setting to tell it to keep quiet and do its job? Most of the old debug messages in semantic are gone. The incremental parser error sounds like a bug that needs some reproduction steps so it can be fixed. The Variables: ... sounds like `semantic-idle-summary-mode'. If you don't like that, you should probably disable `semantic-idle-completions-mode' too. Eric
Re: how to get semantic to shut up
On Wed, 2004-09-29 at 20:46 +, [EMAIL PROTECTED] wrote: Most of the old debug messages in semantic are gone. The incremental parser error sounds like a bug that needs some reproduction steps so it can be fixed. The Variables: ... sounds like `semantic-idle-summary-mode'. If you don't like that, you should probably disable `semantic-idle-completions-mode' too. I'm still getting messages from semantic-edits-incremental-parser (incremental parser error, Update Tag Table: blah, etc.). Looks like there's no easy way to disable these, short of either completely disabling the semantic incremental parser or of redefining working-temp-message to be a no-op. Is there a major disadvantage to doing either of those? Raul
Re: how to get semantic to shut up
On Wed, 2004-09-29 at 16:31 -0700, [EMAIL PROTECTED] wrote: Looks like there's no easy way to disable these, short of either completely disabling the semantic incremental parser or of redefining working-temp-message to be a no-op. Is there a major disadvantage to doing either of those? I would expect that. The key now is to find out what editing situation causes it to throw the error, and to get a stack trace from it next time it occurs. If there is a way to narrow it down, that would be useful. I've rarely seen the error messages, so I'm fine with those happening rarely. But the other messages aren't error messages; semantic-edits-incremental-parser-1 calls working-temp-message for a lot of informative messages. There should be a flag that tells it not to display those, unless you're debugging semantic or happen to care. Raul
Re: [jde] xref *-caller files empty
On Tue, 2004-09-28 at 16:15 +0100, Dominik Dahlem wrote: I'm testing the xref functionality on a small codebase. In my most simple example, I would like to display the call tree of a private method in a class. Also, jde-xref-first-caller results in a message No more calls in my minibuffer. I verified the xrefdb and found out that all *-caller files just contain (). I suppose this is the reason, why I can not navigate through call-trees since the information could not be properly generated. Find below my prj.el file. Am I missing something? Rather than help you with jde-xref, I'd recommend trying the usages plugin, which works much better and provides extra functionality. Check it out at http://jde-usages.sourceforge.net. Are there plans to integrate the usages plugin as a replacement for jde- xref? I don't know any advantages jde-xref has over the plugin. Raul
jde and jsp development using mmm-mode
I'm trying to use mmm-mode for the first time, and it doesn't work very well. Fontification is screwed up... the HTML sections are not fontified correctly, and the JSP sections are always fontified using mmm-default-submode-face, not the faces specified in mmm-sample.el. Apparently there's a regexp error, because in the *Messages* buffer I see messages like this: Error during redisplay: (wrong-type-argument integer-or-marker-p nil) [2 times] And the JSP file is marked modified, even if I just visited it. (Apparently this is because of the above error.) Does anyone have this working? I get this even if all I do is start emacs with -q and load only the following elisp: (global-font-lock-mode t) (setq auto-mode-alist (append '((\\.jsp\\' . html-mode)) auto-mode-alist)) ;(require 'cedet) ;(require 'jde) (require 'mmm-mode) (setq mmm-global-mode 'maybe) (mmm-add-mode-ext-class nil \\.jsp\\' 'jsp) (set-face-background 'mmm-default-submode-face black) It doesn't matter whether I include cedet/JDE, the same thing happens. Raul
problems with method completion
Method completion (jde-complete-menu) has worked for me like a charm in the past. As of recently, it always gives me No completion. Which is weird, because it can complete member variable names, even if the variable is defined in the parent class... but when it comes to completing methods on that variable, I always get no completion available. Ironically, either semantic or JDE is able to show an Emacs popup with the completed method names. This popup menu comes up automatically at random times. Unfortunately I can't select from this popup menu. Is it semantic that creates this menu automatically??? How can I complete/select from it? I'm using JDE 2.3.4beta5, cedet 1.0beta3b, GNU Emacs 21.3.1 on Linux Fedora Core 2. Raul
Re: [jde] Re: Usages plugin problem with deleted classes
On Thu, 2004-09-23 at 16:04 -0700, Suraj Acharya wrote: Was bsh running when you renamed the class? Someone else renamed the class, I simply synchronized my code base. I have since restarted Emacs several times. If the .class file is not in the classpath then getting rid of the files in ~/.jde-usages while bsh is not running should fix the problem. Please let me know if this works; It did!!! Yay!!! :) and keep the old files around as I'd like to figure out how it got into this state originally. Oops, already deleted them. :( Though it sounds like it was a problem with bsh thinking the old class was there, then usages putting it in ~/.jde-usages... and when bsh was restarted, usages telling bsh the old class was there from its ~/.jde-usages files. Bad cycle. Raul
Re: [jde] Color coding only on first java file
On Tue, 2004-09-21 at 23:06 -0400, Paul Kinnucan wrote: There seems to be a bug in semantic that is cured by putting the following in your .emacs file: (setq semantic-load-turn-useful-things-on t) See Jeff Greif's post to the JDEE mailing list earlier today. Is it necessary to restart emacs, or is there something that can be done inside a running emacs to take advantage of this fix? I already have quite a little session of buffers going and I'd hate to restart and have to find all the files, rename the buffers accordingly (I'm editing a bunch of files with the same name so I've renamed the buffers to make it easier to switch), etc. Raul
Usages plugin problem with deleted classes
I'm using the usages plugin, and it's awesome. One problem: a class that got deleted (actually renamed to a different package) a few days ago is confusing it when I lookup subclasses; it somehow finds a reference to the old class, but since it's not compiled and the source is not around, it throws an error. I have looked everywhere and find no reference to the old class; not in jde-sourcepath, not in jde-global-classpath. However, ~/.jde-usages keeps getting recreated with one of the #blah#.classes files having a reference to the deleted class. I have no idea where it is picking up the reference, since the classpath directory for the #blah#.classes file definitely does not have the deleted class in its old package. Since the format of the #blah#.classes file is binary, I can't understand what led it to find the reference. Thoughts? Raul
problems with jde-java-font-lock-constant-face
JDEE beta 5 doesn't consistently fontify constants such as FOO_BAR.
Sometimes it does, sometimes it doesn't. When it doesn't, if I edit the
buffer, it will suddenly fontify properly, but if I reload the file the
proper fontification will go away. For example, if I start up emacs
without my init file (emacs -q), and only do:
(load-file /usr/share/emacs/site-lisp/cedet-1.0beta3b/common/cedet.elc)
(semantic-load-enable-code-belpers)
(require 'jde)
If I load the following file into a buffer:
public class test {
public final static boolean FONT_LOCK_TEST = false;
public void foo() {
System.out.println(FONT_LOCK_TEST);
}
}
FONT_LOCK_TEST will not be fontified. However, if I edit in any way
lines 2 or 4 (that contain FONT_LOCK_TEST), it will be fontified
according to jde-java-font-lock-constant-face correctly. If I then kill
the buffer and revisit the same file, the fontification will go away.
In larger source files, some constants will be fontified, and some
won't. I can't tell what will determine it; code structures such as:
if (foo == FIRST_CONSTANT || foo == SECOND_CONSTANT) { ... }
may fontify the first or second or both. The same constant will appear
fontified in some lines but not others in the same source file. Very
weird. Help?
Raul
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
[jde] problems compiling jde beta 5
I'm using the makefile, with GNU Emacs 21.3.1, on Red Hat 9. I'm including the full build output below. Raul # make test -d ../../cedet-1.0beta2b -a -d ../../elib rm -f *.elc jde-compile-script-init echo (add-to-list 'load-path \.\) jde-compile-script-init echo (add-to-list 'load-path \../../elib\) jde-compile-script-init echo (setq debug-on-error t) jde-compile-script-init echo (load-file \../../cedet-1.0beta2b/common/cedet.el\) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init if test `echo emacs | grep -w xemacs` ; \ then emacs -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else emacs -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ fi; Loading /usr/share/emacs/site-lisp/site-start.d/lang-coding-systems-init.el (source)... Loading /usr/share/emacs/site-lisp/site-start.d/php-mode-init.el (source)... Loading /usr/share/emacs/site-lisp/site-start.d/po-mode-init.el (source)... Loading /usr/share/emacs/site-lisp/site-start.d/psgml-init.el (source)... Loading /usr/share/emacs/site-lisp/site-start.d/python-mode-init.el (source)... Loading /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el (source)... Loading /usr/share/emacs/site-lisp/cedet-1.0beta2b/common/cedet.el (source)... /usr/share/emacs/site-lisp/cedet-1.0beta2b/common/ added to `load-path' /usr/share/emacs/site-lisp/cedet-1.0beta2b/eieio added to `load-path' /usr/share/emacs/site-lisp/cedet-1.0beta2b/semantic added to `load-path' Loading /usr/libexec/emacs/21.3/i386-redhat-linux/fns-21.3.1.el (source)... /usr/share/emacs/site-lisp/cedet-1.0beta2b/speedbar added to `load-path' Debugger entered--Lisp error: (void-function semantic-alias-obsolete) semantic-alias-obsolete(semantic-auto-parse-mode semantic-idle-scheduler-mode) byte-code(... [semantic-add-minor-mode semantic-idle-scheduler-mode ARP nil semantic-alias-obsolete semantic-auto-parse-mode global-semantic-auto-parse-mode global-semantic-idle-scheduler-mode] 4) require(semantic-idle) eval-buffer(#buffer *load*4 nil jde-complete nil t) load-with-code-conversion(/usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde-complete.el jde-complete nil t) require(jde-complete) eval-buffer(#buffer *load*3 nil jde-wiz nil t) load-with-code-conversion(/usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde-wiz.el jde-wiz nil t) require(jde-wiz) eval-buffer(#buffer *load*2 nil jde nil t) load-with-code-conversion(/usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde.el jde nil t) require(jde) eval-buffer(#buffer *load* nil /usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde-compile-script-init nil t) load-with-code-conversion(/usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde-compile-script-init /usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde-compile-script-init nil t) load(/usr/share/emacs/site-lisp/jde-2.3.4beta5/lisp/jde-compile-script-init nil t) command-line-1((-l jde-compile-script-init -f batch-byte-compile beanshell.el efc.el efc-xemacs.el jde-ant.el jde-autoload.el jde-bug.el jde-checkstyle.el jde-class.el jde-compat.el jde-compile.el jde-complete.el jde-custom.el jde-db.el jde-dbo.el jde-dbs.el jde-ejb.el jde.el jde-gen.el jde-help.el jde-imenu.el jde-import.el jde-javadoc.el jde-javadoc-gen.el jde-java-font-lock.el jde-java-grammar.el jde-jdb.el jde-make.el jde-open-source.el jde-package.el jde-parse-class.el jde-parse.el jde-plugins.el jde-project-file.el jde-run.el jde-sregex.el jde-stat.el jde-tree-widget.el jde-util.el jde-which-method.el jde-widgets.el jde-wiz.el jde-xref.el setnu.el tree-widget.el)) command-line() normal-top-level() if test -f jde-compile-script-init; then rm -f jde-compile-script-init; fi;
problems compiling jde beta 5
I'm using cedet-1.0beta2b Raul Debugger entered--Lisp error: (void-function semantic-alias-obsolete) semantic-alias-obsolete(semantic-auto-parse-mode semantic-idle-scheduler-mode)
Re: printing visual diffs?
The Linux version is very nice, and does pretty visual side-by-side diffs... ... with no Print button in sight. Sigh.. Raul Suraj Acharya wrote: I've seen co-workers use perforce's client tool on non-windows machines. http://www.perforce.com/perforce/loadbeta.html I'm not sure if you can print the side by side diffs though. Suraj On Fri, 28 May 2004 11:42:40 -0700, Raul Acevedo [EMAIL PROTECTED] wrote: Chitale, Sandip V wrote: [I know you are asking about printing...] Are you ware of ediff (emacs package) which lets you view diffs side by side? Yes, I mentioned it in my original email, that the ideal is ediff-style printing. I already have ediff integrated into my Perforce diff setup. Raul
[jde] RE: JDE 2.3.4beta3: strange overlining
Thomas Haselberger wrote: I'm getting the weird effect shown in the attached GIF using JDE 2.3.4beta3 and cedet1.0beta2 on Emacs 21.3. All non-public methods are 'overlined', which is really not pleasant. I guess it's some kind of highlighting of non-public methods that has gone wrong - does anybody know of a configuration setting to modify this behaviour or is it possibly a bug? I got rid of it by customizing semantic-highlight-attribute-face-private semantic-highlight-attribute-face-protected semantic-tag-boundary-face That will work, but you probably want to do: (custom-set-variables '(global-semantic-highlight-by-attribute-mode nil) '(global-semantic-show-tag-boundaries-mode nil)) That not only is cleaner, but also faster, since the mode will be completely disabled and its code won't run in the first place. Raul
jde-xref works for some methods, not for others
I have a large project (almost 2,000 Java files), and sometimes jde-xref works in finding callers, sometimes it doesn't. It seems to be on a per-class basis; i.e. any method in class A I can list callers, but in class B no callers are found for any methods. Looking at the xrefdb directory, it looks like the database was created correctly... i.e. the appropriate -caller file looks like it has the correct entry for class B, with all its methods. Any ideas what could be going on? Raul
[jde] cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2
Semantic 2.0 is out??? Paul Kinnucan wrote: Ed == Ed Soniat [EMAIL PROTECTED] writes: Ed I tried install JDEE-2.3.2 which claims compatibility with Ed Semantic 1.blah.blah or greater. Semantic 2.0 deleted Ed semantic-bnf in Aug/03 or so. Ed The change log in JDEE is out of date, makes it look like a Ed dead project. Install JDEE 2.3.3beta6 to get semantic 2.0 support and an updated change log. Paul
Re: occasional error compiling due to jde-xref-compile-hook
Andrew Hyatt wrote: Thanks, this looks like a bug. For the time being, substitute with this line: (add-hook 'jde-compile-finish-hook 'jde-xref-update-caller-table) That isn't defined either and eventually gives me the same undefined error. [1462] /usr/share/emacs/site-lisp/jde/lisp]# grep jde-xref-update-caller-table *.el jde-xref.el: (add-hook 'jde-compile-finish-hook 'jde-xref-update-caller-table) Raul
Re[1]: [jde] cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2
I'd be interested in trying it. :) What would be some of the more obvious benefits to JDEE users? Raul Eric M. Ludlam wrote: Semantic 2.0 lives in cedet-1.0beta1.tar.gz on the cedet web page. There was no formal announcement as I'm still working through build and compatibility issues for various versions of Emacs. In fact, I'm a bit behind on a mountain of reports. For those willing to work around some of the problems, the overall response has been positive. There are a few patches for some problems in the cedet-devel mailing list archive for those brave enough to try it. Eric Raul Acevedo [EMAIL PROTECTED] seems to think that: Semantic 2.0 is out??? Paul Kinnucan wrote: Ed == Ed Soniat [EMAIL PROTECTED] writes: Ed I tried install JDEE-2.3.2 which claims compatibility with Ed Semantic 1.blah.blah or greater. Semantic 2.0 deleted Ed semantic-bnf in Aug/03 or so. Ed The change log in JDEE is out of date, makes it look like a Ed dead project. Install JDEE 2.3.3beta6 to get semantic 2.0 support and an updated change log. Paul -- Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED] Home: http://www.ludlam.netSiege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
occasional error compiling due to jde-xref-compile-hook
I occasionally get the following error when I compile a Java file: error in process filter: Symbol's function definition is void: jde-xref-compile-hook. If I grep for jde-xref-compile-hook in the JDE sources, I find only one reference in jde-xref.el: (add-hook 'jde-compile-finish-hook 'jde-xref-compile-hook) But I don't see the definition of the function jde-xref-compile-hook. What's going on? Raul
missing features in jde?
I've been using JDE for a while, and while I'm generally happy with it, there is some basic functionality that it seems to be missing: * Minibuffer completion on class names for jde-open-class-source. * Find usages functionality: list all callers/users for a given method, field or class. No, I don't want to use grep, I want something 100% reliable. * Functionality to list all classes/interfaces which implement/extend a given class/interface. JDE is great, but these features are pretty standard on most Java IDEs and they are quite useful. Are they there and I've missed them, or will they be provided in a future release? Thanks, Raul Acevedo [EMAIL PROTECTED]
