Re: JDE is slooooow to visit files
James == James Pharaoh [EMAIL PROTECTED] writes: James Hi, James I started using JDE recently and all was fine... As time goes James on, however, it seems to take longer and longer to visit James files. James It takes about 15 seconds now, displaying the message at the James bottom Setting customized JDE variables to startup James values The delay seems to be longer in directories with James lots of source files in. James Any ideas? This is not a slow computer! It's always hard to judge on potential reasons for slowness, but in this case I'll speculate. The project management system of JDEE has to reset quite a lot of variables to their default values. I put some code in to speed this up a while back. But if you have lots of variables set on a per project basis, this will still take a long time. Is this true in your case? The solution would be to only use prj.el for those variables that you need to differ between projects. Phil
Re: Continous Testing
Nascif == Nascif Abousalh-Neto [EMAIL PROTECTED] writes: Nascif Hi all, Nascif I recently learned about this Eclipse plugin: Nascif http://pag.csail.mit.edu/continuoustesting/ The idea of this Nascif plugin is to use idle cycles to run your unit testcases - as Nascif soon as you finish a change, your unit testcases would be Nascif executed (perhaps just the ones for that class) to give you Nascif instant feedback on any bug you might have introduced. Nascif I was thinking on how to implement that for Nascif Emacs/JDEE. Perhaps an extension or hook for flymake could Nascif be used, together with a call to jde-eval - once we know the Nascif class is syntatically correct, we trigger the execution of Nascif the testcases. Or maybe a hook into semantics, since it also Nascif seems to do work in the background now. Nascif What do you think? Any ideas? It's a nice idea. I think that the thing that its going to be hard is interrupting the process when the idle finishes. You can do this straightforwardly when using lisp, but it might be harder if you have to communicate with an external process. Also, for my purposes, all of my tests come from an ant build file, so if it didn't work with this, it's not going to be that useful. Cheers Phil
Re: java folding
Guy == Guy Thomas [EMAIL PROTECTED] writes: Guy I first of all want to have a quick overview of the method Guy signatures in the current file. ECB might be what you are looking for. If this takes up too much screen real estate for you, imenu, or the classes menu might be what you want. Cheers Phil
Re: java folding
Jens == Jens Lautenbacher [EMAIL PROTECTED] writes: Jens On Wed, 2005-02-02 at 11:59 +, Phillip Lord wrote: Guy == Guy Thomas [EMAIL PROTECTED] writes: Guy I first of all want to have a quick overview of the method Guy signatures in the current file. ECB might be what you are looking for. If this takes up too much screen real estate for you, imenu, or the classes menu might be what you want. Jens Still it would be nice to have (as many other IDEs do) e.g. a Jens small + sign in the margin/gutter besides every method to Jens simply hide/show the body of that method. I don't see how this Jens can work currently, at least I never had much luck with the Jens current folding/hideshow or whatever package with java files. You could try jfolding.el. It steals functionality from hideshow and folding mode. Folding mode is a little arachic now, and jfolding is not actively maintained--it was never very well done anyway--but it might work for you. The method folding functionality only uses hideshow (folding.el was used for folding javadoc), so there is more chance that it will work. But you are pretty much on your own. I got bored of this functionality to be honest. ECB, imenu, incremental search, and M-x occur seem to achieve much the same end. Each to his own! Cheers Phil
Re: Auto-format code to width = 80
Jeffrey == Jeffrey Phillips [EMAIL PROTECTED] writes:
Jeffrey Not sure about auto-format, but I highlight (my warning
Jeffrey face is red) the part of lines that extend past 80
Jeffrey characters using this:
Jeffrey (defun my-font-lock-prepends (mode)
Jeffrey Adds a 80 character line-width (font-lock-add-keywords
Jeffrey mode '((\\(.\\{80\\}\\)\\(.+\\)
Jeffrey 2 font-lock-warning-face prepend
Jeffrey (my-font-lock-prepends 'jde-mode)
Jeffrey -jeffrey
Jeffrey On Tue, 14 Dec 2004 09:01:20 -0500, Mark D. Hansen
Jeffrey [EMAIL PROTECTED] wrote:
Can anyone tell me how to configure emacs/jde so that my java
code will auto-format to have column width 80?
Auto-Formatting is hard because it coming up with something that looks
really nice is difficult.
I use wide-column.el which is slightly less intrusive than the
directly using font lock. It changes the cursor colour as your line
gets beyond length and says hit return some time, hit return.
http://www.russet.org.uk/download/emacs/wide-column.el
Cheers
Phil
Installation Guide
I was fiddling around with JDEE at home last night, and I noticed that the installation guide is actually not included with the download bundle. As my internet connection was hosed at the time this was a little bit of a pain. Not a major pain, as I know how to install JDEE, but none the less. There are quite a few questions on this list which get read the installation guide answers. I'm wondering if there would be fewer if the guide were in the download. Preferably with a big file called INSTALL in the root directory point out the location of the (local) installation guide. Is there a reason why it isn't included? Cheers Phil
Re: Investigating quickfix functionality
Kai == Kai Grossjohann [EMAIL PROTECTED] writes: Kai I had been using Eclipse for some time a year ago. One thing I Kai really liked about it was the quickfix functionality. When the Kai compiler found an error in your source code, you could hit Kai Ctrl+1 to pop up a little menu which suggested some remedies. Kai Because I missed it so much, I investigate whether it would be Kai possible to get this in Emacs, as well. It seems it would be Kai possible in principle. Kai This version only knows two kinds of errors: unreported Kai exception, and cannot resolve symbol class Foo. Kai I'd appreciate any comments or help or patches. Kai What do people think? Kai I think this sort of functionality would be great, particularly within JDE. I'd make a couple of suggestions though; First, I think you want to factor out the qfix code from the refactoring functionality of which you already have some. The latter will be useful in their own right. Second, I think you will need to make, qfix-unreported-exception-regexp and similar variables into lists. I use jikes to compile in general (because it gives error column info as well as line), and I am sure others will use different compilers still. Finally, I guess that you are on the CVS version of emacs. next-error-last-buffer doesn't exist in mine. Cheers Phil
Re: [jde] Re: refactoring in jdee
Raul == Raul Acevedo [EMAIL PROTECTED] writes: Raul On Thu, 2004-09-30 at 13:58 -0400, Matt Kurjanowicz wrote: The ability to change class names as well would be awesome :) Raul Yes, that would be cool also. In terms of priority, I'd Raul rather see variable and method refactoring first, since that's Raul a bit more common. Raul With jde-usages in place, adding this to JDEE would be one of Raul the last major steps towards it being as full featured as Raul commercial IDEs. :) Method push up, and pull down would be good as well. Using something like jrefactory would be another option. However, it regenerates the refactored classes entirely, which is a bit of a pain, as it reformats the whole class. Cheers Phil
Re: Suggestion: jde-run-application-class
Jayakrishnan == Jayakrishnan Nair [EMAIL PROTECTED] writes: Jayakrishnan Hi, Jayakrishnan While writing a large program, I put public static Jayakrishnan void main() in different classes, so that I can run Jayakrishnan them independently. If I need to switch the main Jayakrishnan program, I have to customize jde-run-application-class Jayakrishnan each time. Usually I am switching between a list of Jayakrishnan say 5 programs. So it would be convenient if in the Jayakrishnan customize window I can enter a list and select one Jayakrishnan from that as the main program to run. Jayakrishnan This would save some time. Jayakrishnan Cheers, Jayakrishnan JK I do this something like this. It makes a menu item then allows you to set the main class to the current buffer. Or to unset it again. I do the same for toggle between different ant programs (antm is my own program so probably this is of no interest to anyone else) and verbosity level. It falls short of what you want but its cheap and cheerful and should give you the basic functionality you need. Cheers Phil (defvar jde-more (list JDE+ [Set as main classphil-java-set-as-main-class t] [No main classphil-java-unset-main-class t] [Toggle ant program phil-java-toggle-ant-program t] [Toggle ant verbose phil-java-toggle-ant-verbose t])) (easy-menu-do-define 'jde-more jde-mode-map Additn Menu for JDE jde-more) (defun phil-java-set-as-main-class() Sets the current class as the main class (interactive) (let ((main (concat (jde-db-get-package) (file-name-sans-extension (file-name-nondirectory (buffer-file-name)) (message Setting %s as main class main) (setq jde-run-application-class main) (jde-save-project))) (defun phil-java-unset-main-class() Sets the current class as the main class (interactive) (message Unsetting main class) (setq jde-run-application-class nil) (jde-save-project)) (defun phil-java-toggle-ant-program() Toggle between ant/antm (interactive) (cond ((equal ant jde-ant-program) (progn (setq jde-ant-program antm) (jde-save-project) (message Setting ant program to antm))) ((equal antm jde-ant-program) (progn (setq jde-ant-program ant) (jde-save-project) (message Setting ant program to ant))) (t (message Don't recognise existing program, giving up (defun phil-java-toggle-ant-verbose() Toggle verbose ant (interactive) (cond ((equal -emacs jde-ant-args) (progn (setq jde-ant-args -emacs -verbose) (jde-save-project) (message Setting ant to verbose ))) ((equal -emacs -verbose jde-ant-args) (progn (setq jde-ant-args -emacs) (jde-save-project) (message Setting ant to non verbose))) (t (message Don't recognise existing options, giving up
Re: Constructor, enumeration templates and functions
Paul == Paul Landes [EMAIL PROTECTED] writes: Paul Phillip Lord writes: It's possible to do this using a super class. I use the class following. Paul This is one approach. Both have their advantages and Paul disadvantages. It might be a bad idea to use inheritance for Paul immutable instances because now your sharing implementation Paul details across classes. I thought sharing implementation between classes was the point of inheritance. Paul You can give your super class some unique identifier, but as Paul you add more things (i.e. description, identifiers, sub enums, Paul etc.) you now have to consider these changes in overriden Paul java.lang.Object methods like equal() and hashCode() for both Paul performance and maintenance reasons. Perhaps I am missing the point again. It's a enum. equal() is never overridden because an == comparison is what you want. Paul I like the template approach because this gives me a template Paul to work with, then I can specialize it for what I need. I often add new things to my enums though. Mostly I inherit straight from the AbstractEnumeration I sent it. Sometimes I create another generic subclass in between. Perhaps I'm being biased here. It's just templated code where inheritance will work gives me the willies. I also wonder whether its worth doing this when Java is getting language support for Enums in 1.5 Paul Perhaps not. There are many of us that are still on, and will Paul be stuck on 1.4, for a while. I my situation, we have to pick Paul and commit to a J2EE application server. J2EE vendors tend to Paul be slow to upgrade Java versions. True enough. I work in research so we can generally use what ever we like! I understand that most people don't have this luxury (or curse depending on how you look at it!). Cheers Phil
Re: Constructor, enumeration templates and functions
Paul == Paul Landes [EMAIL PROTECTED] writes:
Paul Here is something I needed wrote this weekend. What this
Paul provides is:
Paul Templates:
Paul - jde-gen-enum: an `enumeration' class, which is a static
Paul collection of identifiers much like C `enums' but object
Paul oriented. The generated class is optimized for
Paul serialization and used as keys.
It's possible to do this using a super class. I use the class
following.
I also wonder whether its worth doing this when Java is getting
language support for Enums in 1.5
Cheers
Phil
/*
*This library is free software; you can redistribute it and/or
*modify it under the terms of the GNU Lesser General Public
*License as published by the Free Software Foundation; either
*version 2.1 of the License, or (at your option) any later version.
*
*This library is distributed in the hope that it will be useful,
*but WITHOUT ANY WARRANTY; without even the implied warranty of
*MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
*Lesser General Public License for more details.
*
*You should have received a copy of the GNU Lesser General Public
*License along with this library; if not, write to the Free Software
*Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package uk.ac.man.cs.img.discoveryview.util; // Generated package name
import java.io.ObjectStreamException;
import java.io.Serializable;
import java.util.ConcurrentModificationException;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.NoSuchElementException;
/**
* AbstractEnumeration.java
*
* Provides support for Enumerated Types in Java. This class provides
* several methods useful for all Enumerated Types including a
* sensible printable toString method, the total
* number of instances of a given type, an Iterator through all the
* types, and an ordinal number running from 0 upwards for each type. p
*
* This class is used by extending it with a new class which
* ul
*liis declared final, which prevents subclasses from
* introducing new instances/li
*lihas a private constructor/li
*lideclares a public static final data member for each instance
* that is required/li
* /ul
*
* So for example
*
* code
* pre
* public final class TrafficLight extends AbstractEnumeration
* {
* private TrafficLight( String toString ){
* {
* super( toString );
* }
*
* public static final TrafficLight RED
* = new TrafficLight( TrafficLight Enumerated Type:- RED );
* public static final TrafficLight ORANGE
* = new Traffic( TrafficLight Enumerated Type:- ORANGE );
* public static final TrafficLight GREEN
* = new Traffic( TrafficLight Enumerated Type:- GREEN );
* }
*
*/pre
* /code
*
* Currently this class can not be serialised. Having one of the
* subclasses implement Serializable would be a mistake as it would
* provide an alternative route for the instances of the class to be
* produced. This could be circumvented using the
* replaceObject/writeObject methods introduced in the 1.2
* serialisation spec, but I haven't got around to implementing this
* yet!
*
* It should be noted that there are problems in compiling this class
* with some versions of javac. This is bug in javac (Bug ID:4157676),
* not my code which is perfectly legal java. Jikes works
* fine. Alternatively you can comment out the references to the ord
* variable and do without this functionality, or make it non final,
* in which case attempts to alter it will no longer produce compiler
* errors as they should.
*
* Created: Mon Feb 21 14:11:41 2000
*
* @author Phillip Lord
* @version $Id: AbstractEnumeration.java,v 1.1 2004/02/27 14:26:36 lordp Exp $
*/
public abstract class AbstractEnumeration implements Serializable
{
// A linked list of all these types.
private String toString;
private AbstractEnumeration next;
private AbstractEnumeration prev;
// private static hashtables, which support the enum
// implementation. We are using hashtables because they are
// synchronized and they need to be for this!
private static Hashtable upperBoundHash = new Hashtable();
private static Hashtable firstHash = new Hashtable();
private static Hashtable lastHash = new Hashtable();
private static Hashtable currentTopOrd = new Hashtable();
// ordinal number. Very useful.
public final int ord; //if this does not compile its a bug in javac. Removing
final should make it work
protected AbstractEnumeration( String toString )
{
super();
this.toString = toString;
// sort the ordinal number for this type.
// first retrieve it (if it exists) from the hash
Object upBound = upperBoundHash.get( getClass() );
int upperBound;
if( upBound == null ){
upperBound = 0;
}
else{
upperBound = ((Integer)upBound).intValue();
}
// make the upper
Re: jde-import-all
Petter == Petter Måhlén [EMAIL PROTECTED] writes: Petter == Petter Måhlén [EMAIL PROTECTED] writes: Petter Found another little nit to pick. I have a class named Petter Task, and when I run jde-import-all for that class, I am Petter prompted to import some class named sun.something.Task. I am Petter not enough of an elisp person to see how, but maybe Petter jde-import-all-expand-strip-exclude should exclude the Petter current class as well? The functions that actually do the import come from JDEE core itself rather than me. In this case the `jde-import-excluded-packages' variable should do what you want (exclude sun.* classes). The current class, and classes in the current package should already be excluded. If this isn't happening then its a bug but probably not mine. Petter Aha, I saw it slightly differently: if I am presently Petter working on a class called Task, and the jde-import-all finds Petter an unqualified name of Task, it shouldn't bother trying to Petter import it. That's why I suggested that the current class Petter should be removed before even looking for classes to import. Petter Anyway, I looked into it (and realised that maybe one of Petter these days I am going to have to drop my claim of not Petter knowing any elisp... terrible thought), and came up with the Petter below possible solution, which seems to work as far as I can Petter tell. Would that make sense to you? It makes sense yes. I didn't bother because I think it gets caught anyway. But I will add this change. Petter By the way, I am afraid I came up with another case that Petter doesn't quite work, and which I think may be difficult to Petter catch with a regexp: calling a static method in another Petter class, like: Petter Logger.getLogger(); Petter Maybe a regexp that assumes that something that starts with Petter a capital letter, followed by a dot is a class to be Petter imported? A bit shaky to me. Still, even without it, this Petter is a command that I will be using a lot. This is a known issue. I am debating with myself the logic of this package. It might just make sense to look for all occurrences of words beginning with capital letters not in comments. I can't think of any way of identifying static calls short of this. Here is a new version of jde-import-all.el which at least checks for return types. I've re-worked the bulk import removal also. Cheers Phil ;;; jde-import-all.el --- Import everything at once. ;; Copyright (C) 2004 Phillip Lord ;; Author: Phillip Lord [EMAIL PROTECTED] ;; COPYRIGHT NOTICE ;; ;; This program is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with this program; see the file COPYING. If not, write to the ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;;; Commentary: ;; ;; Build imports for all types in the buffer. This package has two ;; entry points. `jde-import-all' finds all declared types in the ;; buffer, then presents the user with a nice dialog which they can ;; then choose as many as they wish. `jde-import-all-unambiguous' ;; finds all the declared types in the buffer, and then imports ;; without asking the user any imports which identify a class ;; unambigiously. ;; ;; There are not user options other than those in `jde-import' which ;; this respects. ;; ;; This package is really meant for rolling into jde-import. There's ;; also a dialog near the end which uses the efc namespace, because it ;; probably belongs there. ;; ;; This package uses regexp searching to find all the types, as the ;; semantic grammar doesn't appear to go deep enough for use ;; here. Like other parts of JDE it depends on use of coding standards ;; (upper case for types). It will miss types not conforming to this. ;; ;; There is also fledgling support for mass import removal. The ;; `jde-import-all-kill-extra-imports-in-project' ;;; Bugs: ;; ;; This does not correctly identifer InnerClasses which need to be ;; imported via their parent. Probably requires both lisp and ;; beanshell support. ;; ;;; History: ;; ;; - fixed bug with regexp, which failed to pick up implements ;; types, or multiple types after extends ;; ;;; Code: (require 'sregex) (require 'jde-import) (defun jde-import-all-regexp() Get the regexp set to find all types. ;; I'm starting to have doubts about this regexp. Its very nice, ;; very large, and works. However it goes
Re: jde-import-all
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul Phillip Lord writes: Here is the latest version of jde-import-all, which works with jde-2.3.3. Paul Hi Philip, Paul How about leveraging semantic to find a candidate list of Paul classes to import? The following function uses the semantic Paul lexer to get a list of all Java tokens in the current Paul buffer. It then extracts all identifiers in the list that Paul start with an upper case character and have at least one lower Paul case character, and that do not appear in an import statement Paul or inner or outer class declaration. Paul I'd thought about using semantic. I thought that the parser was not doing a full parse though...does it actually work its way down into method definitions or just forward-sexp over them? If it does work in identifying all the types then semantic is clearly the way to go. Paul A more rigorous approach might use David Ponce's wisent parser Paul generator to generate a parser that builds a list of class Paul names as a side effect of parsing the buffer. Yes I would agree. I'm unlikely to have time to do this though. I was looking for a quick solution which basically worked! Cheers Phil
Re: jde-import-all
Here is the latest version of jde-import-all, which works with jde-2.3.3. Cheers Phil ;;; jde-import-all.el --- Import everything at once. ;; Copyright (C) 2004 Phillip Lord ;; Author: Phillip Lord [EMAIL PROTECTED] ;; COPYRIGHT NOTICE ;; ;; This program is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with this program; see the file COPYING. If not, write to the ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;;; Commentary: ;; ;; Build imports for all types in the buffer. This package has two ;; entry points. `jde-import-all' finds all declared types in the ;; buffer, then presents the user with a nice dialog which they can ;; then choose as many as they wish. `jde-import-all-unambiguous' ;; finds all the declared types in the buffer, and then imports ;; without asking the user any imports which identify a class ;; unambigiously. ;; ;; There are not user options other than those in `jde-import' which ;; this respects. ;; ;; This package is really meant for rolling into jde-import. There's ;; also a dialog near the end which uses the efc namespace, because it ;; probably belongs there. ;; ;; This package uses regexp searching to find all the types, as the ;; semantic grammar doesn't appear to go deep enough for use ;; here. Like other parts of JDE it depends on use of coding standards ;; (upper case for types). It will miss types not conforming to this. ;;; Bugs: ;; ;; This does not correctly identifer InnerClasses which need to be ;; imported via their parent. Probably requires both lisp and ;; beanshell support. ;; ;;; History: ;; ;; - fixed bug with regexp, which failed to pick up implements ;; types, or multiple types after extends ;; ;;; Code: (require 'sregex) (require 'jde-import) (defun jde-import-all-regexp() Get the regexp set to find all types. (let ((white-nl '(1+ (or (syntax ?-) \n))) (white-nl-0 '(0+ (or (syntax ?-) \n))) (non-identifier '(1+ wordchar)) ;; match an upper case begining word, which we will take as a ;; type. (identifier '(group (char (?A . ?Z)) (1+ wordchar (list (cons ;; match anything following instanceof, new, or extends. These ;; are keywords, so are guarenteed to be classes (sregex '(or new instanceof throws) white-nl '(group (1+ wordchar))) 1) (cons ;; match anything following extends or implements. This will ;; then be split on commas. Both extends and implements can ;; carry multiple Class names after them, as Interfaces can ;; extend multiple other interfaces. (sregex '(or extends implements) white-nl-0 `(group (1+ (or ,identifier , (syntax ?-) 'jde-import-match-comma-split) (cons ;; match anything in between parens and starting with upper ;; case. This picks up casts. This will also pick up things like ;; debugGraphics.setDebugOptions(FLASH_OPTIONS); where ;; FLASH_OPTIONS is actually a static. Generally this won't be a ;; problem because it shouldn't resolve as a class. ` (sregex '(char ?( ) identifier '(char ?))) 1) ;; match an .class type thing.. (cons (sregex identifier .class) 1) ;; match variable declaration (cons (sregex white-nl identifier white-nl non-identifier white-nl-0 '(or ; =)) 1) ;; match formal parameters (cons (sregex '(or ( ,) white-nl-0 identifier white-nl non-identifier white-nl-0 '(or , ))) 1) ))) (defun jde-import-all-get-types() Return all the types in the current buffer. The result is a list with no duplicates. (let ((elements)) (mapcar (lambda(matcher) (let ((matches (jde-import-all-gather matcher))) (mapcar (lambda(match) (add-to-list 'elements match)) matches))) (jde-import-all-regexp)) elements)) (defun jde-import-all-gather(matcher) Get all matches in the current buffer. MATCHER is a cons (regexp . group). Looks for matches to the regexp and stores the match in the group. Only matches not in strings are accepted. This list can
Re: jde-import-all
Petter == Petter Måhlén [EMAIL PROTECTED] writes: Petter This looks like something I would use a lot, although I Petter haven't tried it yet. I'll give it a shot when I have the Petter time. I'm find it very useful. Petter Love the comment to jde-import-all-kill-extra-imports :) I'm less enamoured with the comment to be honest. I just tried this on a reasonable size code base and its done bad things to my code! Very dangerous. Phil
Re: jde-import-all
Petter == Petter Måhlén [EMAIL PROTECTED] writes:
Petter I've tested this a bit now, and I really like it. I have
Petter found one slight problem, and I have one request for a
Petter possible improvement:
Petter 1. It doesn't detect the need to import List with the
Petterfollowing class:
Petter public class Hej {
Petter public Hej() { }
Petter public List hejsan() { }
Petter }
Petter I guess it doesn't check for return types? It may seem like
Petter a non-valid use case, but in my case, I had a method that
Petter instantiated a LinkedList but with a signature returning a
Petter List.
No this is entirely valid. I do this myself a lot. You are right it is
missing those. I will try and work up a good regexp for this.
Petter 2. If possible, and this is something that I have always
Petterwanted for the
Petter dialogs, I would like the cursor to be positioned on the Ok
Petter button by default. That way, I can just hit return to
Petter confirm the selection. That probably is only valid in the
Petter one-hit case here, not when the user actually has to go
Petter through and select lots of stuff, so it's not really a big
Petter deal.
I think that this is a valid issue and have thought about it myself.
If you look at code for creating a dialog though you get this...
(defmethod efc-dialog-show ((this efc-dialog))
;; stuff chopped
(use-local-map widget-keymap)
(widget-setup)
;; Position cursor over OK button.
;; (forward-line 0)
(goto-char (point-min))
(pop-to-buffer (oref this buf)))
In otherwords this functionality was there at one point but its been
commented out. I'm not sure why, but I think that there is a
usability issue here. If the dialog box is long which is distinctly
possible with the import dialog, the prompt line at the top of the
dialog may end up off screen.
I can think of two possible solution. First this method is changed to
enable the programmer to put the ok and cancel but at the
top. This way its a simple tab to get to the ok button.
Alternatively, and I think a better option, would be to set the dialog
in a specialised mode to add some extra keybindings to run the ok or
cancel functionality where ever point is. This way you could click
as many buttons as you choose and then do C-cC-c or similar to
confirm, and maybe C-cC-k to kill the dialog box. I think is
probably the easier solution.
But it requires changes to core JDE which is why I didn't do it in the
short term.
Cheers
Phil
Re: jde-import-all
Petter == Petter Måhlén [EMAIL PROTECTED] writes: Petter Found another little nit to pick. I have a class named Petter Task, and when I run jde-import-all for that class, I am Petter prompted to import some class named sun.something.Task. I am Petter not enough of an elisp person to see how, but maybe Petter jde-import-all-expand-strip-exclude should exclude the Petter current class as well? The functions that actually do the import come from JDEE core itself rather than me. In this case the `jde-import-excluded-packages' variable should do what you want (exclude sun.* classes). The current class, and classes in the current package should already be excluded. If this isn't happening then its a bug but probably not mine. Cheers Phil
Re: speeding up variable loading
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: I've had a go at implementing the first solution. The second one is a little more wide ranging and I think would have unexpected consequences. For instance using buffer-local variables would mean that you could not disable context switching, which I think you do temporarily during debugging. I've attached a jde-custom.el file which implements the defjdecustom method. It seems to be working for me at the moment. Paul Hi Phil, Paul I'd like to suggest another approach to this problem. I've Paul implemented it in my sandbox and it seems to work fine. I'd Paul like to get feedback from you and others on it. Paul The proposed approach is the following. Paul I have created a new command called jde-customize-option. This Paul command displays a standard customization buffer with two Paul additional features: Paul (1) The Set menu has a new Save to Project Paul option. Selecting this Paul option sets the option to its customized value, saves the Paul value in the current project file, and adds the variable to Paul the JDEE's dirty variable list. (2) The existing Erase Paul Customization option now erases the customization and then Paul deletes the variable from the current project file. This Paul solution not only eliminates the need for a defjdeoption macro Paul it also eliminates the need to execute an additional command Paul to save or delete the variable from the project Paul file. Accordingly, I propose changing the jde-save-project Paul option from a command to a function. Paul How does this strike you? Paul I think that this is probably a neater solution than the defjdecustom solution as I said the other day. I thought it would be more work but you seem to have done it quickly enough, so I would definitely go for it. On the second topic, that is removing jde-save-project as a command, I would disagree. I partially generate my project file using an ant task that I have written, and so I use jde-save-project to create a skeleton. Having said this, I do so rarely so removing it's menu and keybinding would be fine. Of course push comes to shove I can always use `eval-expression'. I'm quite surprised here. My original patch was just to speed up project file switching rather than anything else. Things seem to have moved further in a short space of time! Cheers Phil
Re: speeding up variable loading
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: On the second topic, that is removing jde-save-project as a command, I would disagree. I partially generate my project file using an ant task that I have written, and so I use jde-save-project to create a skeleton. Having said this, I do so rarely so removing it's menu and keybinding would be fine. Of course push comes to shove I can always use `eval-expression'. Paul I think it would be better to change jde-save-project to be a Paul function to discourage people from trying to customize Paul variables outside the customize system and thereby unwittingly Paul corrupt their project files. I can understand why you would want this. As I say I can work around it in many ways. Which reminds me of something that I've been meaning to do for a while. I know you like custom because it reduces the number of problems you get. But I still like setting things in my .emacs because its easier to version and comment. I wanted to write a function called custom-setq which works like a normal setq but crashes if there is a type mismatch. Having spent a few days of playing with custom I think I can actually see how to do this now! The only difficulty I can see is that the defcustom form would have to have been eval'd before the custom-setq which isn't true of defvar and setq forms. Anyway this is totally off-topic! Cheers Phil
Re: speeding up variable loading
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: This will also make it easy for third parties to piggy back into the JDE project system I think, without having to use the jde- namespace which the system currently depends on. I'd be quite happy to give this a go if you'd like. Might take a day or two (it's pub night tonight!). Paul Okay. Your assignment, should you choose to accept it, is to Paul create a macro named defjdeoption. It should do everything Paul that defcustom does plus store a customized variable on the Paul dirty variables list and offer the user the option to save a Paul customization to the current project file. I shall give this a go when I get home tonight. Incidentally I think that there might be a better, if longer term solution. When you start customise from a JDE buffer the customise buffer knows which project you are talking about because it shares the same default-directory as the JDE buffer. So it should be possible to override defcustom to set its variable in a buffer-local variable, and then set all the other buffers in the same project to be the same thing. After all the only reason that project file switch has to happen at all is because defcustom doesn't do buffer-local variables. You could then relegate project files to do what they do best which is serialise the options out so that they get set between sessions (or for newly visited files in an existing project). Still if the project file switching happens quickly enough this is probably just not an issue, so it may be more effort than it's worth... Cheers Phil
Re: speeding up variable loading
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: I have thought of one occasion when this will work differently from as now. Possibly better, possibly worse. If you have just set a variable using customise, but not saved it, and then you switch projects, it will not get reset to its default. I think this is unlikely to be a problem. If you are working on two projects, and you customise a variable you generally save it straight away. Otherwise it gets reset as soon as you change project. I'm not sure this new behaviour is any better or worse than before therefore. Paul Yes, this problem occurred to me after my previous post. The Paul problem is worse because it can lead to corruption of project Paul files. Suppose you have projects A and B open. Now suppose you Paul customize variable X that still has its default value in both Paul projects in a project A buffer and save A's project file. At Paul this point, the list of dirty variables has still not been Paul updated. Now, suppose you switch to project B and customize Paul variable Y and save the project file. Now both X and Y will be Paul stored in B's project file though you intended X to have its Paul default value in project B. Paul The only solution to this problem that I can see is to provide Paul a custom-set function for JDEE variables that updates the Paul dirty variable list whenever the user customizes a variable Paul during a session. Since the custom-set function is also Paul invoked by the defcustom macro to set the variable s default Paul value, the JDEE's custom-set function would have to detect Paul that it is being invoked by a defcustom macro and not update Paul the dirty variable list. This change will require adding the Paul set function to every defcustom form in the JDEE code base but Paul is probably worth it. I thought about this solution. It has the minor disadvantage that it will not work for non JDE variables that use the JDE namespace to piggy back into the project file mechanism. I seem to remember having used this in the past when I wrote JDE add-on packages. I think that there is a simpler solution though. Either modify the function that generates the project file to add all of the variables that its saved to the dirty-list. Or alternatively modify the save-project-file functionality to immediately load-project-file which will have the same effect. Alternatively you could just write a defjdecustom macro to add the functionality to defcustom. Lars Unspellable does something similar in Gnus with his deffoo macro. Cheers Phil
Re: speeding up variable loading
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: I thought about this solution. It has the minor disadvantage that it will not work for non JDE variables that use the JDE namespace to piggy back into the project file mechanism. I seem to remember having used this in the past when I wrote JDE add-on packages. I think that there is a simpler solution though. Either modify the function that generates the project file to add all of the variables that its saved to the dirty-list. Or alternatively modify the save-project-file functionality to immediately load-project-file which will have the same effect. Paul I thought of this and discarded it because it works only if Paul the user saves a customization in the project file. True enough. I guess that your scenario is more destructive than the current behaviour (where the user just looses their customisation on moving to project B). Alternatively you could just write a defjdecustom macro to add the functionality to defcustom. Lars Unspellable does something similar in Gnus with his deffoo macro. Paul I'll probably go this route, which Eric Ludlam suggested as Paul well. This will also make it easy for third parties to piggy back into the JDE project system I think, without having to use the jde- namespace which the system currently depends on. I'd be quite happy to give this a go if you'd like. Might take a day or two (it's pub night tonight!). You loose the nice fontification of defcustom in the lisp though. Ain't there always something! Cheers Phil
Re: Clicking from exceptions to source lines
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul Charles Sutton writes: Hi, If an application I'm running prints out the stack trace of an exception, is there a command that will parse the stack track trace output and bring up the relevant source line in a buffer (similar to what's done with compile errors)? If not, I might take a look at it. Paul Click mouse button 2 over the stack trace line you want to Paul visit or enter one of the following commands: Paul jde-run-etrace-next jde-run-etrace-prev Paul jde-run-etrace-show-at-point As Paul says etrace does the job. I augment it with this code which defines a minor mode, for switching the keybindings on and off. This is useful for log files for instance, where you also want Emacs to understand stack traces. (defvar jde-run-etrace-mode-map (make-sparse-keymap)) (define-key jde-run-etrace-mode-map \C-c\C-v\C-[ 'jde-run-etrace-prev) (define-key jde-run-etrace-mode-map \C-c\C-v\C-] 'jde-run-etrace-next) (define-key jde-run-etrace-mode-map [mouse-2] 'jde-run-etrace-show-at-mouse) (easy-mmode-define-minor-mode jde-etrace-mode Jump to stack trace nil etrace jde-run-etrace-mode-map) Phil
Re: JDEE and Ant and paths
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul Phillip Lord writes: Kai == Kai Großjohann [EMAIL PROTECTED] writes: Kai I have some lengthy class path statements for compilation in Kai build.xml, and I thought it would be cool if JDEE could make Kai use of that for C-c C-v C-z and friends. Then I wouldn't have Kai to update the paths in two places. -- Two cafe au lait please, Kai but without milk. This is something that I would also love to have. And as well as class path, I'd like to add to the javadoc locations, specify a main class, and so on. I have not come up with a good solution yet, although there are a couple of possibilities. Paul I use David Ponce's JMaker facility for make. It generates a Paul multilevel set of makefiles for the current project, i.e., a Paul makefile for each package that is invoked by a toplevel Paul makefile. JMaker uses JDEE variables, e.g., Paul jde-global-classpath, jde-compiler, etc., to generate the Paul paths for the compiler and the classpath. JMaker really Paul works. The generated makefiles build the project without any Paul hand tuning and its a snap to regenerate the makefiles when Paul you add classes or packages to a package. Paul Perhaps somebody could provides a similar JDEE plugin for Paul Ant. It would be possible, but wouldn't work for me. The build I am using is developed for many different people, most of whom do not use JDE. The communication really has to go the other way. I guess that a simple solution would be to split `jde-project-file-name' conceptually into two, which would be `load-file-name' and `save-file-name'. Then I could set the classpath up as @CLASSPATH@, and have ant rebuild prj.el as appropriate. Writing a specific ant task with this in mind, which could be distributed with JDE, would isolate users from changes in the way JDE uses variables. Phil
Re: JDEE and Ant and paths
Kai == Kai Großjohann [EMAIL PROTECTED] writes: Kai I have some lengthy class path statements for compilation in Kai build.xml, and I thought it would be cool if JDEE could make Kai use of that for C-c C-v C-z and friends. Then I wouldn't have Kai to update the paths in two places. -- Two cafe au lait please, Kai but without milk. This is something that I would also love to have. And as well as class path, I'd like to add to the javadoc locations, specify a main class, and so on. I have not come up with a good solution yet, although there are a couple of possibilities. You could use a replace task in ant, and fill in your classpath as @CLASSPATH@ or some such. The only difficulty with this is that JDE by default saves to prj.el. To get this to work you would need to get it so save to prj.src.el (or whatever) and load from a prj.el generated by ant. The other possibility is this ant task here... http://i3sp-build.sourceforge.net/javadoc/com/i3sp/ant/JdeProject.html I've not tried this yet. The documentation suggests that it creates a prj.el, which would be no good for me, as I would want it to update an existing prj.el. It would also be sensitive to changes in the underlying types of the various entities in the prj.el. Let me know if you can think of a better alternative! Phil
ant and JDEE prj.el files
I was wondering if anyone had done any work on integrating JDE prj.el files and ant. I would quite like JDEE to pick up various options (well mostly the classpath!) as it has been set by ant. The calculation of this in ant is currently fairly involved, and its a pain to have to duplicate this in the JDEE files. If not, I may have a go myself, if I can find the time. I can think of two main possibilities 1) Use one of ANT's FilterReader rules to do some sort of regexp matching on the prj.el file. This should work, except that the prj.el file will have to be manually reloaded, if point is currently within the project (which is quite likely). 2) Use an exec to launch gnuclient, and run custom-set-value or some such some, to directly change the value. Of course then the user will have to manually save the prj.el file. Of course, gnuclient could do that, but this might be undesirable if the user has manually change over variables that the do not want saving. Also this sort of assumes that point is currently within the project, or the wrong project file will get changed. I'm sort of leaning toward the former. Has anyone done something similar? Any one got opinions? Phil
Re: jde-open-class-at-point on import statements
Herve == =?windows-1252?Q?Herv=E9 Bitteur?= windows-1252 writes: Herve Hello, Herve The behavior of jde-open-class-at-point (bound do C-c C-v Herve C-y) is strange when the point is on the following statement: Herve import java.util.Collection; ..^ Point Herve here Herve It just issues a message saying Can not parse the thing at Herve point! Herve I tried a little bit of debugging, and discovered that it Herve tries to interpret the leading prefix (here java.util) as Herve the name of a class, just as if we had a statement like : As a related point this also happens in full qualified names within the class rather than in the imports
Re: Why the JDEE?
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul It also allows users who are, like myself, working in a Paul multilanguage environment (e.g., C/C++/Java) to use a single Paul environment for all their work. This is my primary motivation for using emacs, and JDE for java. I use many different languages. And often ones for which big flashy IDE's are not available. Besides why would I want to learn three different ways of accessing version control for instance? With Emacs it's always there, and its always the same. Paul In my view, the JDEE's greatest deficiency in this Paul regard is in debugging support. I would have to agree with this. For many years I have used Java quite happily without a debugger, and, of course, its quite feasible to do this. But recently I spent 5 months writing perl. Now this is a language which its nearly impossible to write without a debugger. Coming back to Java, I find that I miss it quite a bit. Phil
Re: JDEE plugins (was JUCI)
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul Hi Nick, Paul I am posting my response to your idea of JUCI-based plugins Paul to the JDEE list because I am interested in getting other Paul people's Paul input on this idea. This sounds like a thoroughly good idea to me. I've contributed lisp to JDE in the past, which is very easy to do, but I've never added Java, because I never got the build working on a unix box. I was looking at jrefactory the other day, and thought that would be nice to integrate in, but it needs some Java code in the way. And then the whole thing needs to be made available to JDE, so that it can be run from bsh. A simple plugin architecture would make this all easier. So, yeah, sounds sensible to me. Phil
Re: prj.el under source control
Nascif == Nascif Abousalh-Neto [EMAIL PROTECTED] writes: Nascif Hi, Nascif I recently added our prj.el files to source control Nascif (clearcase) but soon after that I start to get some strange Nascif behavior - basically related to loss of customizations, like Nascif modeline, font-lock, key bindings, and project name. I'm not Nascif sure it is related, but I'm thinking that the fact that fact Nascif that the prj.el is now read-only may be causing Nascif problems. Could that be the case? Nascif Another variable: I recently migrated from Nascif jde2.2.9beta10 to Nascif jde2.2.9. I tried to move back but the problem persisted. Do you have templates with CVS keywords in them? If so when you check the prj.el out, they will get expanded, and it will all go horribly pear shaped. There are a couple of ways around this. My normal solution is to set the flag which stops keyword expansion. Phil
Re: prj file and moving project
Heinz-Dieter == Heinz-Dieter Conradi [EMAIL PROTECTED] writes: Heinz-Dieter hi all, Heinz-Dieter i occassionally move project between computers or make Heinz-Dieter a test copy into a different location. what always Heinz-Dieter irrates me about this process is the prj.el file. Heinz-Dieter since i would like to have the same properties, i see Heinz-Dieter no point in clicking myself to the options. after all, Heinz-Dieter most of the time all i have to do is modify the Heinz-Dieter starting directory in the global classpath, the Heinz-Dieter sourcepath and perhaps some other properties too. Heinz-Dieter is there any way that the prj file could determine Heinz-Dieter it's own directory? so that e.g. instead of Heinz-Dieter '(jde-global-classpath (quote (/first/path) Heinz-Dieter (/path/to/prj/directory)) Heinz-Dieter one could write something more generic and portable? Heinz-Dieter tia for any ideas, heinz-dieter conradi .., and presumably . are interpreted correctly by the project file system, relative to the location of the project file. So for instance I have directory structure like so... top-level/src top-level/classes top-level/lib and so on, where top-level is whatever you want to call you top-level directory. From the prj.el file (which is in src) I have the following settings... '(jde-global-classpath (quote (../classes ../lib ../lib/build))) which is completely relocatable. This is important for me, as we have several developers using JDE, so I tend to check prj.el into CVS, so that I an maintain it for everyone. Clearly it has to be relocatable. I run under unix, but several of the developers are using windows, and it seems to work for both. Cheers Phil
Re: JDEE and emacs-wiki
Daniel == Daniel Serodio [EMAIL PROTECTED] writes: Daniel Well, I've found some more info on this error. emacs-wiki Daniel defines a line-beginning-position function with 1 optional Daniel argument, and jde-bug defines a function with the same name Daniel but no arguments. Daniel In emacs-wiki.el: Daniel (unless (fboundp 'line-beginning-position) Daniel (defsubst line-beginning-position (optional N) Daniel (save-excursion (beginning-of-line N) (point Daniel In jde-bug.el: Daniel (when jde-xemacsp Daniel (defun line-beginning-position () Daniel (point-at-bol)) Daniel (defun line-end-position () Daniel (point-at-eol))) Daniel How can I solve this conflict? Thanks for any help. Sadly you can't. Really the best way to do these things would to remove (when jde-xemacsp (defun line-beginning-position... and instead have (defun jde-line-beginning-position() (or (when jde-xemacsp (point-at-bol) (line-beginning-position or some such. Obviously you would also need to change every reference to line-beginning-position in JDE, but it would resolve the name clash. Alternatively after loading JDE you could do (defsubst line-beginning-position (optional N) (save-excursion (beginning-of-line N) (point which will force the definition of the function with the optional argument. From a quick look at the definitions it should all work. The other option would be to change all the references to line-beginning-position in JDE to point-at-bol, as an alias for this (to line-beginning-position) already exists in Emacs. Wow. Complicated eh? Phil
Re: jde-open-class-at-point error?
Andreas == Andreas Vallen [EMAIL PROTECTED] writes: Andreas Hi Andreas I have some trouble trying to find out why Andreas 'jde-open-class-at-point' does not work as it should. I get Andreas the error-message: Can not parse the thing at point when Andreas applying the function to the name of a class that is Andreas imported via an import statement with an asterisk: Andreas import package.*; Andreas Rewriting the statement to Andreas import packagename.Classname; Andreas makes the error go away! Andreas Note that the JDK classes are found either way. Using the Andreas lisp debugger I found that it is the Beanshell which Andreas seemingly chokes on this: 'jde-parse-class-exists' which Andreas invokes the Beanshell does not find the class. Andreas The Beanshell runtime classpath contains the searched for Andreas classes. Any advice? Use the fully qualified names for imports. It's much more future proof. When java 1.2 came out all my code which had import java.awt.*; import java.util.* broke because of a name clash over list. In the end more useful for other programmers as well, as they don't have to guess which of several packages a class might belong to. JDE has utilities for enabling you to do these sort of imports without actually having to type them, so its easy to do. I seem to remember someone suggesting putting functionality into to do all the required imports in a new buffer automatically. Don't know if that functionality has gone in yet. Shouldn't be too hard to write. Cheers Phil
Re: Javadoc comments
Nick == Nick Sieger [EMAIL PROTECTED] writes: Nick Thanks for the nifty code, Klaus. Your `my-cc-mode-return' Nick function led me to wonder if there was a way to make Nick auto-fill/filladapt obey string semantics. It'd be slick if Nick hitting space after the fill-column would close the current Nick string and re-open it in the proper way on the next line. I Nick looked at the lisp code for auto-fill/filladapt but did not Nick see any obvious hooks to make this work. Anyone have an idea? Probably better to bind this to a key and do it manually. Several short strings catenated together will probably before significantly worse than a single long one, and should happen by programmer choice, when it doesn't matter (debug, or fatal error reports), rather than automatically. Also its very easy to do this way (defun insert-new-string-line() (interactive) (insert \ +\n) (insert \) (indent-according-to-mode)) Cheers Phil
augmenting prj.el with hand crafted code
Is there anyway to augment the prj.el with hand written lisp? I have tried writing lisp directly into the prj.el file, but this doesn't work well for two reasons. Firstly JDE keeps on kill the buffer after project switching. Secondly for reasons I have not quite worked out yet, it seems to remove all empty lines which makes the hand written code unreadable. The problem I have is this. I would like to set up jde-db-source-directories so that it works automatically for people. I currently have it set up to ../src which is appropriate for the project. However this does not include the java.* source which is a, er, source of irritation to me. As developers are using a variety of platforms, I need to use different paths, to get to networked versions of the JDK source accessible. I have similar problems with setting up docsets. I realise that hand crafted source will involve setting JDE variables using setq, rather than custom. I promise that I will under no circumstances say why is JDE crashing when this is because I have set up a JDE variable in the wrong way. I would rather use custom but I don't think I can. Cheers Phil
Re: Why JDEE ?
Troy == Troy Daniels [EMAIL PROTECTED] writes: Troy At 01:30 PM 2/25/02 -0500, Paul Kinnucan wrote: John Cobo writes: Paul, Am I correct in thinking that your JDEE allows a single set up of the JDK, Emacs, Tomcat, Web server, any shared JAR, WAR files for the development team, etc. on a shared server. Developers can then 'simply' access the environment through a window on to the server ? Troy At my company, the Unix disks can be mounted on the PC using Troy samba, so that it looks like a network drive. I then run Troy emacs on my PC, and can read and compile the files on the Unix Troy disk. Actually running the code requires a window on the Unix Troy machine*. This may work better or worse, depending on (at Troy least) the availability of samba, and whether the net lag is Troy worse for interacting with emacs or for writting the class Troy files. Another possibility would be to have a go with TRAMP, which is ange-ftp for the new millenium. I use it across ssh, which works very well. I've not tried it on windows though, and I don't know how much JDE functionality it would break. I'd be interested to know. Phil
Re: Whay is JDE/Xemacs startup so slow?
Michael == Altmann, Michael [EMAIL PROTECTED] writes: Michael Do other people find that it takes 20 secs to load jde? Michael This seems excessively long. I am running xemacs 21.1 on a Michael solaris server box (I'm not sure its exact speed). Without Michael jde it takes just a second to start xemacs. There are many Michael messages about loading regexp-opt on the status line. Is Michael there some sort of debug I should turn on to track what it Michael is doing? JDE does take quite a long time to load. I'm not sure about 20 seconds, but as I load JDE, and several other modes at the beginning of the day, I've never really measured the time of JDE on its own. There are a couple of options. First why are you starting xemacs frequently. I start my emacs once at day at most (unless I am developing an emacs package). gnuserv might be what you are looking for. The other option (if you have the space, or relevant permissions) might be to redump your own emacs. I've done this with psgml mode in the past, and I think JDE. Essentially the lisp image gets included in the executable, and so does not need to be loaded. Perhaps someone on the list has exact instructions. I decided it was more effort than it was worth, but your may differ. Cheers Phil
Re: compiling packages
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul Phillip Lord writes: In my experience ant is generally quicker because it launches all compiles from a single JVM, while make will tend to launch javac for each out of date file, which means multiple JVM invocations. Paul The makefile generated by JMaker uses a single invocation of Paul javac to compile all classes in a package. It is very fast in Paul my experience. Does it now? You learn something every day! I shall have to take a peek, see how it does it. Cheers Phil
Re: compiling packages
Madeleine == Arnold, Madeleine [EMAIL PROTECTED] writes: Madeleine Hi there I'm a JDE newbie of 2 days. Can anyone help with Madeleine this question: Is there a way in JDE to compile all Madeleine classes within a particular package? I've found the build Madeleine command that calls javac on the application's main class, Madeleine but my application has several packages, and I often want Madeleine to recompile only a particular package rather than the Madeleine entire application. Thanks Madeleine Using one of the standard build tools is probably the way to go. JDE supports make and ant directly, and M-x compile will work with anything that you choose. Also the JMaker package from David Ponce (which I think comes with JDE these days) will build make files for you automatically. In my experience ant is generally quicker because it launches all compiles from a single JVM, while make will tend to launch javac for each out of date file, which means multiple JVM invocations. Cheers Phil
Re: best features of jde
Stephane == Stephane [EMAIL PROTECTED] writes: Stephane I plan to give a coure about jde and to introduce this IDE Stephane to my new pupills next january. What would you show to Stephane emacs-beginners ? What are your favorites jde's features I find automatic documentation look up, and source navigation using `jde-open-class-source' to be the features of JDE that I use most frequently. The code completion stuff is nice as well, although I because its mouse driven I tend to use hippie-expand where I can. To be honest though the two features that I think you should show to beginners (I presume these are beginner programmers as well as new to JDE), are not actually features of JDE per se, but rather of other parts of Emacs. These are automatic code indentation. When I used to teach my students used to think that I insisted on good indentation as a form of sadism. And secondly introduce them to the version control facilities. If you can install PCL-CVS mode (or are using Emacs 21) then do. To my mind version control is vital to any sort of development process. Emacs provides a nice enough interface to several vc systems, and teaching your students to use them will benefit them enormously. Phil
Re: [ANNOUNCE] XSLT-process 2.0 available
I haven't used either of them yet, but it looks to me like this package has a lot of overlap with the XAE which Paul has written. Are there plans to merge the two? Phil
Extending the java syntax
I was just wondering whether there were any plans to modify the JDE to cope with the extended Java syntax found in the new genericity proposal. http://java.sun.com/aboutJava/communityprocess/review/jsr014/index.html Phil
Re: Turing auto gen off in comments
Stephen == Molitor, Stephen [EMAIL PROTECTED] writes: Stephen Is there any way to turn auto code generation off in Stephen comments? For example, when I type 'If' at the beginning Stephen of a sentence in a comment, it gets automatically converted Stephen to lower case 'if', and I have to go back and change it. The code generation facility is driven by emacs' abbreviation mode. I wrote the tmmofl package to switch minor modes on and off in comments (or another region of text identified by its syntax highlighting). With JDE it does what you want. I also have it switching auto-fill mode on in comments so that you don't have to new line. Anyway feel free to try it. Phil http://bioinf.man.ac.uk/~lord/applications/emacs/emacs-packages.html
Re: ANN: JDE 2.2.7beta7 available at ...
"Paul" == Paul Kinnucan [EMAIL PROTECTED] writes: Paul At 10:31 AM 4/14/2001 -0700, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Kinnucan [EMAIL PROTECTED] writes: snip * If'ed out fontifying exception stack trace in run buffer when running in XEmacs. This is temporary until I can code an alternative to font-lock-add-keywords, which XEmacs does not support. snip Where did this code come from? Was this my jde-stack.el package? Paul It is basically Sam Steingold's version of Philip Lord's Paul original work combined with the fontification code in Paul jde-stack.el. In what file is it in? Yeah gods, what is this monster that I have created! I wonder how many different versions there are of jde-stack now? Phil
Re: GDB for Debugging Java Programs
"Nic" == Nic Ferrier [EMAIL PROTECTED] writes: Matthew G Knepley [EMAIL PROTECTED] 28-Feb-01 5:23:29 PM I believe that the docs are refering to gcj which is a GNU layer on top of gcc that can compile byte code to the GNU IR which is subsequently compiled by gcc. The drawback fothis approach is that all the native functions stuck the in JDK are not part of this process, and thus lots of stuff is not supported (like AWT). Nic At the risk of extending this thread beyond it's natural Nic lifetime I'd like to make a couple of corrections here: Sorry but I had to respond to this... Nic - GCC now includes Java as a language and the JVM as a Nic complilation target (it's not a layer - it's a part of GCC, Nic just like Modula-2 support). The java support with gcc is actually a layer, as indeed is the modula-2 support. gcc was written in the first place to provide multiple language support, by providing a relatively clean interface between the language specific code and the backend assembly production stuff. At least this is how I understand it. Nic - There is an issue with the GCC calling convention, the JVM Nic standard is JNI whereas as GCC compiled code uses a convention Nic called CNI. This allows better integration between Java and Nic other native code. Nic It is NOT true to say that lots of stuff is not supported or Nic that the native functions in the JDK "are not part of the Nic process". GCC uses the GNU-Classpath free implementation of the Nic JDK. Actually it is true The point is that you Sun release a full implementation of the Java api's. Logic would say therefore that if your compiler (gcj in this case) can compile java, all you would have to do is compile Sun's code, and you would have the class libraries that you needed. This fails because the functionality provided by native code is not specified in the language spec. So the native functions that would have to provide are specific to the java implementation being used. The practical upshot of all of this is that gcj requires a complete API implementation rather than just a (much smaller) set of native code implementation. This is explained in detail at http://gcc.gnu.org/java/faq.html#2_1 Nic This does not *yet* include the AWT (it is being developed) or Nic Swing but it does include nearlly everything else from Java 2. Nic When AWT is finished it will be faster than any other Java Nic platforms implementation because of the improved calling Nic interface. This is a premature conclusion I think. Its certainly a hope but we will have to wait and see. Phil
feature proposal for jde-run
Knut I think it would be a good idea if jde-run accepted the Knut universal argument, which would cause jde-run to prompt me Knut what class to run with a default of the public class in the Knut current buffer, and jde-run w/o the universal argument would Knut work as before, using the jde-run-application-class variable. This code does pretty much what you want... Phil (defun jde-run (optional arg) "Run the Java application specified by `jde-run-executable', if not the null string. Otherwise run the class specified by `jde-run-application-class', if non-null; otherwise the class in the current buffer. This command also creates a comint buffer to allow you to interacti with the program." (interactive "p") (if (string= mode-name "JDE") (if (not (= 1 arg)) (let((jde-run-application-class (read-from-minibuffer "Enter main class name: "))) (jde-run-impl)) (jde-run-impl)) (error "The jde-run command works only in a Java source buffer."))) (defun jde-run-impl() (if (string= jde-run-executable "") (jde-run-main-class) (jde-run-executable)))
Re: JDE 2.2.7beta2 available at ...
"Jeff" == Jeff Rancier [EMAIL PROTECTED] writes: Jeff Paul, Jeff Could it be a difficult addition to see from the JDE-Help Jeff menu to view the current versions of the required sub-packages Jeff as well as the JDE's version? E.g. Perhaps it might even be possible to have JDE check the version numbers and emit a warning if they are wrong. I know that JDE carries a variable containing a version number. Some of the other packages do not (as far as I can see) but I am sure that the authors would be willing to incorporate them. Come to think of it, its probably time that emacs had a full version dependency checking. Still as it hasn't for now Phil
Re: Generating import statements automatically?
"T" == T V Raman [EMAIL PROTECTED] writes: T JDE never ceases to amaze me --(whine , whine) too much good T stuff hidden under menus-- guess you never win:-) T Would be even nicer if it handed the java file to bsh --found T what symbols didn't resolve, and then invoked the import wizard T on each unresolved symbol. (Rather emacs spent its cycles doing T that than looping inside the semantic abovinator:-) It should be relatively easy to do this I would have thought. Emacs already knows which symbols within the buffer are type declarations (either from the font-lock information, or via semantic). JDE's import wizard is also intelligent enough to only import those classes which have not been already imported. So scanning through the former and invoking the later should do all that is necessary. The only thing that will need changing are those cases where the imports are ambiguous. Currently JDE sticks up a widget driven dialog to choose between them. I guess when running in "non-interactive mode" it should just put up an error message saying "the symbol List was ambiguous" and let the user do this manually. You could even get really clever, if this ran quickly enough, and scan the buffer before compile was run. I've been meaning to write this for some while myself, as the approach that I take (run a compile, jump to errors, run the import) is rather long winded. Most of the code is already in the JDE though, so it would not be too hard if someone wanted to do it. Phil
