SV: Jde-import.el
Oops, forgot to copy the list for the below response: I am not quite sure that I agree that it is a blunt solution. The reason is that according to the specification, classes from two packages are always available: those from the current package and from java.lang. This means that unless you explicitly specify that another x.y.String class should be used, the one from java.lang will be used. So in my opinion, the solution only does what the compiler does anyway. It uses classes imported implicitly if possible, and tries to import them explicitly otherwise. I think that more than 99.9% (or even 99.99%) of all uses of String are java.lang.String, so it is also better to optimise for that case than for the rare one when another String is needed. And the same probably goes for most of the classes in java.lang. I think that a behaviour similar to that is more intuitive than requiring users to configure some variables since only power-users are likely to be aware of the existence of those variables, and if the default behaviour is unexpected, it will be ticking people off. But although I think the behaviour is right, I am not sure about the implementation, which most likely could be better. Does that make sense? / Petter -Ursprungligt meddelande- Från: Paul Kinnucan [mailto:[EMAIL PROTECTED] Skickat: den 8 juli 2004 07:00 Till: Petter Måhlén Kopia: [EMAIL PROTECTED] Ämne: Jde-import.el Petter Måhlén writes: Hi Paul, The patched jde-import.el is attached. Basically, what it does is to create the list of fully expanded potential classes to import for each token, as before. Then, it checks if any of the classes belongs to java.lang or the current package, and if so, excludes all of them. Hi Petter, This seems to be a rather blunt solution to the problem of synonyms for java.lang classes. What if I really do want xyz.String instead of java.lang.String? May I suggest the following solution. Suppose the JDEE includes, in addition to jde-import-exclude-packages, jde-import-exclude-classes? The new variable allows you to exclude individual classes without excluding an entire package. In particular, you coulde exclude xyz.String and java.lang.String without exculding other classes from the xyz package. Paul
SV: SV: Jde-electric-return sometimes off
You may have something there, Suraj, because I am setting it in .emacs, since I want it to be on for all Java files I work with. / Petter -Ursprungligt meddelande- Från: Suraj Acharya [mailto:[EMAIL PROTECTED] Skickat: den 1 juli 2004 00:15 Till: Paul Kinnucan Kopia: Petter Måhlén; [EMAIL PROTECTED] Ämne: Re: SV: Jde-electric-return sometimes off Paul, I think the problem might occur if you set jde-electric-return-p in your .emacs (using custom-set-variable) and don't set in your jde project files.Petter, are setting the variable in your .emacs or your project file? I've just upgraded to jde beta5 from beta3 so I'm not sure there is new jde custom variable code that calls the :set methods for variables set globally when switching projects or loading a new one. Suraj On Wed, 30 Jun 2004 08:01:11 -0400, Paul Kinnucan [EMAIL PROTECTED] wrote: Petter Måhlén writes: Well, have to correct myself - the 'toggle' function has been changed to jde-electric-return-mode in beta5, the text referred to beta3. Nevertheless, the behaviour as such is the same in both betas, that is, the electric return doesn't work automatically for newly opened files. I can't reproduce this problem on my system. Please note that intended behavior is for you to use the customization variable jde-electric-return-p to specify the default setting for this mode (on or off) and jde-electric-return-mode to toggle the setting temporarily during a session. Paul / Petter -Ursprungligt meddelande- Från: Petter Måhlén [mailto:[EMAIL PROTECTED] Skickat: den 30 juni 2004 10:16 Till: '[EMAIL PROTECTED]' Ämne: Jde-electric-return sometimes off Hi, I like the jde-gen-embrace functionality that Suraj provided and that is included in the last few betas. However, that feature is often turned off when I open up a new buffer, even though jde-electric-return-p is true. I can turn the feature on by doing two jde-toggle-electric-return (not one), but it should work from the start. My guess is that the key-mapping doesn't take when I open or create a new buffer, could that be true? I have tried to understand what goes on, but haven't quite gotten there. I'm on 2.3.4beta5, by the way. / Petter
Jde-electric-return sometimes off
Hi, I like the jde-gen-embrace functionality that Suraj provided and that is included in the last few betas. However, that feature is often turned off when I open up a new buffer, even though jde-electric-return-p is true. I can turn the feature on by doing two jde-toggle-electric-return (not one), but it should work from the start. My guess is that the key-mapping doesn't take when I open or create a new buffer, could that be true? I have tried to understand what goes on, but haven't quite gotten there. I'm on 2.3.4beta5, by the way. / Petter
SV: Jde-electric-return sometimes off
Well, have to correct myself - the 'toggle' function has been changed to jde-electric-return-mode in beta5, the text referred to beta3. Nevertheless, the behaviour as such is the same in both betas, that is, the electric return doesn't work automatically for newly opened files. / Petter -Ursprungligt meddelande- Från: Petter Måhlén [mailto:[EMAIL PROTECTED] Skickat: den 30 juni 2004 10:16 Till: '[EMAIL PROTECTED]' Ämne: Jde-electric-return sometimes off Hi, I like the jde-gen-embrace functionality that Suraj provided and that is included in the last few betas. However, that feature is often turned off when I open up a new buffer, even though jde-electric-return-p is true. I can turn the feature on by doing two jde-toggle-electric-return (not one), but it should work from the start. My guess is that the key-mapping doesn't take when I open or create a new buffer, could that be true? I have tried to understand what goes on, but haven't quite gotten there. I'm on 2.3.4beta5, by the way. / Petter
RE: jde-import-all
Hi, I'm aware of the first problem. I'll take a look at your solution. Meanwhile a workaround (which I use) is to set jde-import-exclude-imports to filter out the undersirable apache classes. Yes, but that's a little bit cumbersome. I am presently using the modified code I posted and it appears to be OK, but for one thing: in addition to the check for java.lang, a check for classes in the same package should be added. The point being that any class in java.lang or the current package are to be considered imported by default, and that jde-import-all should therefore not try to import those. / Petter
JDE 2.3.4beta3: strange overlining
Hi, 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? / Petter attachment: jde-screen.gif
RE: jde-import-all
I've tested this a bit now, and I really like it. I have found one slight
problem, and I have one request for a possible improvement:
1. It doesn't detect the need to import List with the following class:
public class Hej {
public Hej() {
}
public List hejsan() {
}
}
I guess it doesn't check for return types? It may seem like a non-valid use
case, but in my case, I had a method that instantiated a LinkedList but with
a signature returning a List.
2. If possible, and this is something that I have always wanted for the
dialogs, I would like the cursor to be positioned on the Ok button by
default. That way, I can just hit return to confirm the selection. That
probably is only valid in the one-hit case here, not when the user
actually has to go through and select lots of stuff, so it's not really a
big deal.
Thanks for a very nice feature!
Petter
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Phillip Lord
Sent: den 12 mars 2004 11:41
To: [EMAIL PROTECTED]
Subject: 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
RE: jde-import-all
Found another little nit to pick. I have a class named Task, and when I
run jde-import-all for that class, I am prompted to import some class named
sun.something.Task. I am not enough of an elisp person to see how, but maybe
jde-import-all-expand-strip-exclude should exclude the current class as
well?
I like your suggestion for the key bindings in the dialog as well, that
would be perfect.
/ Petter
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Phillip Lord
Sent: den 12 mars 2004 15:21
To: [EMAIL PROTECTED]
Subject: 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. Aha, I saw it slightly differently: if I am presently working on a class called Task, and the jde-import-all finds an unqualified name of Task, it shouldn't bother trying to import it. That's why I suggested that the current class should be removed before even looking for classes to import. Anyway, I looked into it (and realised that maybe one of these days I am going to have to drop my claim of not knowing any elisp... terrible thought), and came up with the below possible solution, which seems to work as far as I can tell. Would that make sense to you? By the way, I am afraid I came up with another case that doesn't quite work, and which I think may be difficult to catch with a regexp: calling a static method in another class, like: Logger.getLogger(); Maybe a regexp that assumes that something that starts with a capital letter, followed by a dot is a class to be imported? A bit shaky to me. Still, even without it, this is a command that I will be using a lot. / Petter (defun jde-import-all-expand-strip-exclude(list) Qualifies, strips and excludes imports. This function takes in a list of imports. It removes all the existing imports, qualifies them and then strips excluded imports. It returns a list of lists of strings. And all in one function. (delq nil (mapcar (lambda(unqualified-class) ;; we want to remove any imports which already exists and also ;; not bother with the current class (if (or (jde-import-get-existing-import unqualified-class) (string-match unqualified-class (file-name-sans-extension (file-name-nondirectory (buffer-file-name) nil (jde-import-exclude-imports ;; we want to kill of the java.lang ;; packges. exclude-imports will probably do this for ;; us. But this is not good as it will leave the other ;; possibilities. So String will be imported as ;; apache.xpath.String (on my machine) which is almost ;; exactly the wrong behaviour ;; ;; I'm not really happy with this but what can you do. (jde-import-all-kill-lang-classes ;; we want to expand any unqualified names, this returns ;; a list of string possibilities (jde-jeval-r (concat jde.util.JdeUtilities.getQualifiedName(\ unqualified-class \);)) list)))
RE: auto newline, indent and close brace on open brace, return
Hi,
This seems like a good idea to me, but I had two problems when trying it
out. First, I got an error message saying something like if: wrong number
of arguments. I then tried the following update which I think is correct
(added parentheses around the else clause):
(define-key jde-mode-map [return]
(lambda ()
(interactive)
(if (save-excursion
(backward-char)
(not (looking-at {}?$)))
(newline-and-indent)
;; else
((newline-and-indent)
(newline-and-indent)
(when (not (looking-at }))
(insert })
(c-indent-command)
)
(previous-line)
(c-indent-command)
But then I got an error message saying: if: Invalid function:
(newline-and-indent). Where is newline-and-indent defined?
/ Petter
-Original Message-
From: Suraj Acharya [mailto:[EMAIL PROTECTED]
Sent: den 3 mars 2004 13:55
To: [EMAIL PROTECTED]
Subject: auto newline, indent and close brace on open brace, return
Intellij does this thing where if you type a open curly brace
and then a
return it inserts a matching closing brace and puts point
on a empty line between the braces and indents the two
newlines. So if
before you had:
pubic void function () {
^
You now have:
pubic void function () {
}^
Simple but handy.
(define-key jde-mode-map [return]
(lambda ()
(interactive)
(if (save-excursion
(backward-char)
(not (looking-at {}?$)))
(newline-and-indent)
;; else
(newline-and-indent)
(newline-and-indent)
(when (not (looking-at }))
(insert })
(c-indent-command)
)
(previous-line)
(c-indent-command)
)))
Suraj
PS: The above is slightly more complicated than needs be
because I use
Erik Hilsdale's balanced.el which, among other things, automatically
inserts matching close parenthese when you type any kind of open
parentheses.
RE: complete
The buffer to look in is the one called *Messages* (I think it might have a different name on XEmacs). But as Paul says, the best thing to do when asking for help is using the JDE/Help/Submit Problem Report function in the menu. That is, provoke the error, then do a Submit Problem Report. That will generate a large buffer with all the necessary information for people to try to solve the problem. Just email that to this list. / Petter -Original Message- From: Richard Martin [mailto:[EMAIL PROTECTED] Sent: den 19 februari 2004 11:29 To: Paul Kinnucan Cc: Suraj Acharya; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: complete Thanks for your help everyone - I think I'm getting somewhere. It now says Beanshell eval error. See messages buffer for details. but in the bsh buffer there is no error output - am i looking in the wrong place? On Thu, 2004-02-19 at 05:49, Paul Kinnucan wrote: Suraj Acharya writes: Unless something has changed recently you would also need to setup your jde-global-classpath to point to the classes generated from these sources. Your classpath for bsh also has the directories from your sourcepath. If you are using a beanshell 2.0 jar and you know that bsh can parse your .java files without any problems you might be ok, but otherwise you need to jde-sourcepath to include only your src directories and put in all external jars and directories or jars of genrated classes in jde-global-classpath. Yes. Completion works only for compiled classes specified on jde-global-classpath plus the JDK classes. Completion does not use jde-sourcepath. Richard, it would help if you filed a complete problem report and told us the paths of the classes that the JDEE is failing to complete. Paul Suraj Richard Martin wrote: Thanks for your help My version of jde is jde-2.3.2. I have nothing in my prj.el since I am setting all the options in the menus. my source path is [INS] [DEL] Path: ~/workspace/product/ota/src/ [INS] [DEL] Path: ~/workspace/product/axis/src/ [INS] [DEL] Path: ~/workspace/product/db/src/ [INS] [DEL] Path: ~/workspace/product/net/src/ [INS] [DEL] Path: ~/workspace/product/netsh/src/ [INS] [DEL] Path: ~/workspace/product/spine/src/ [INS] [DEL] Path: /data/JBoss-2.4.10_Tomcat-3.2.3/jboss/lib/ext/jboss.jar the output from the bsh buffer is cd /users/richard/workspace/product/ota/src/system/servlet/ /usr/java/jdk1.3.1_04/bin/java -classpath /usr/share/xemacs/xemacs-packages/etc/jde/java/bsh-commands:/u sr/java/jdk1.3.1_ 04/lib/tools.jar:/opt/java/jakarta-ant-1.5/lib/ant.jar:/opt/ja va/jakarta-ant-1.5/lib/clover.jar:/opt/java/jakarta-ant-1.5/li b/genjar.jar:/opt/java/jakarta-ant- 1.5/lib/junit.jar:/opt/java/jakarta-ant-1.5/lib/optional.jar:/ opt/java/jakarta-ant-1.5/lib/xercesImpl.jar:/opt/java/jakarta- ant-1.5/lib/xml-apis.jar:/usr/share/xemacs/xemacs-packages/etc /jde/java/lib/checkstyle- all.jar:/usr/share/xemacs/xemacs-packages/etc/jde/java/lib/jak arta-regexp.jar:/usr/share/xemacs/xemacs-packages/etc/jde/java /lib/jde.jar:/usr/share/xemacs/xemacs-packages/etc/jde/java/li b/bsh.jar:/users/richard/workspace/product/ota/src/:/users/ric hard/workspace/product/axis/src/:/users/richard/workspace/prod uct/db/src/:/users/richard/workspace/product/net/src/:/users/r ichard/workspace/product/netsh/src/:/users/richard/workspace/p roduct/spine/src/ bsh.Interpreter BeanShell 1.2.7 - by Pat Niemeyer ([EMAIL PROTECTED]) bsh % Cheers Richard Paul Landes wrote: Auto completion uses bsh to do classpath lookups using `jde-sourcepath'; are you setting this? We don't have much to go on, can you please post your prj.el, JDEE version (`jde-version') and any other configuration, please. Richard Martin writes: Hi I have been using JDEE for a while but I cant get auto complete to work on my own classes. It says No completions available at this time. My entire project builds (with and without ant) so I must have my classpath setup correctly. Is there something else I need to set? I noticed that there bsh-commands directory in my xemacs packages - do i need that or is that only present in later versions? Thanks Richard -- Richard Martin [EMAIL PROTECTED] AePONA Ltd
RE: gen get/set methods leaves trailing space on gets
I think I have found your problem, Jeff. The highlighted line below includes
a space after the () of the method signature. I have jde-gen-kr set to
true, but I am getting the following type of signature:
public Date getWorkDate() {
return this.m_workDate;
}
Note the double spaces between the () and the {. I tried simply deleting the
trailing space in the line below, and that seems to work fine. Maybe that's
it, Paul?
/ Petter
(defun jde-wiz-get-get-method(type name optional staticp optional
class-name)
Returns a string representing a get method
(let ((filtered-name (jde-wiz-get-name name))
get (javadoc ) temp temp2)
(setq
get
(concat
\n
(if jde-wiz-include-javadoc
(progn
(setq temp2 jde-wiz-get-javadoc-template)
(while temp2
(setq temp (car temp2))
(while (string-match %n temp)
(setq
temp
(replace-match
(jde-wiz-downcase-initials filtered-name) nil nil temp)))
(while (string-match %t temp)
(setq temp (replace-match type nil nil temp)))
(setq javadoc (concat javadoc temp \n))
(setq temp2 (cdr temp2)))
javadoc))
public (if staticp static )
type (if (string= type boolean) is get)
== (upcase-initials filtered-name) ()
(if jde-gen-kr { \n{) \n
return (if staticp (concat class-name .) this.)
name ;\n}\n))
get))
-Original Message-
From: Jeff Jensen [mailto:[EMAIL PROTECTED]
Sent: den 19 februari 2004 17:08
To: [EMAIL PROTECTED]
Subject: RE: gen get/set methods leaves trailing space on gets
Thanks a lot for checking, Paul.
I have not customized any of the templates.
I have reviewed Jde Gen Get Set Var Template and
jde-gen-method-signature,
and see no extra space even possible (but I am no lisp
expert, so could have
missed something simple)!
It is even more odd that it happens on gets and not sets! To
me, that points
to the template. The template is unmodified from the 2.3.3 release.
I will wait for the next release and hopefully this minor nit is gone!
Thanks again
-Original Message-
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 19, 2004 12:15 AM
To: Jeff Jensen
Cc: [EMAIL PROTECTED]
Subject: RE: gen get/set methods leaves trailing space on gets
Jeff Jensen writes:
Hi Paul,
Attached is a sample class with the trailing space on the
get signature
lines.
Note the sets do not have one.
To create, I created the two instance variables, placed
point at the end
of the
class, clicked JDE -- Code Generation -- Wizards --
Generate Get Set.
Using JDE 2.3.3.
Thanks Paul...
Hi Jeff,
I still cannot reproduce this problem. I've made some changes to the
jde-gen-get-set
template. My changes could have fixed the problem. Another
possibility is
that you have a customized version of the template in a prj.el file
that has the extra space in it.
Paul
-Original Message-
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 12:31 AM
To: Jeff Jensen
Cc: ed
Subject: gen get/set methods leaves trailing space on gets
Jeff Jensen writes:
Hi Paul,
Generating get/set methods leaves a trailing space on the
generated get
methods' signature, and not on the sets. Would you mind
removing the
trailing space from the generated gets?
This is obviously a very minor nit, but it triggers a
Checkstyle rule,
requiring manually deleting that space all the time.
Hi Jeff,
Please you send me an example of the generated code
pointing out
where the trailing space occurs. I can't reproduced it
on my system.
Paulpublic class TrailingSpace
{
int num = 4;
String name = Fred;
/**
* Gets the value of num
*
* @return the value of num
*/
public int getNum()
{
return this.num;
}
/**
* Sets the value of num
*
* @param argNum Value to assign to this.num
*/
public void setNum(int argNum)
{
this.num = argNum;
}
/**
* Gets the value of name
*
* @return the value of name
*/
public String getName()
{
return this.name;
}
/**
* Sets the value of name
*
* @param argName Value to assign to this.name
*/
public void setName(String argName)
{
this.name = argName;
}
}
RE: request help on functionality
Hi, Take a look at the JDE-Find-Expression menu alternative. It's also described in the user's guide (under Searching Source Code), and is nearly what you are looking for, I think. / Petter -Original Message- From: Torsten Geise [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2004 08:29 To: [EMAIL PROTECTED] Subject: request help on functionality Hi folks, is there a jde-function to find all usages of the function under the cursor or something like that. I'm using the official debian sid package jde 2.3.2. Thanks for any hints. Torsten. p.s.: thanks to paul and all other developer for this nice java ide and debugger.
RE: request help on functionality
I know. :) I said it's nearly what you want. What you do want has been discussed a lot on this list over the last years, and there seems to be many ways of doing it, but not yet a final solution. At least not that I can remember, although I have been away for months at a time and things may have happened then. Be that as it may, I think the pattern searching will get you a long way, even though it is not 100%. / Petter -Original Message- From: Torsten Geise [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2004 10:18 To: Petter Måhlén Cc: JDEE-Mailinglist Subject: RE: request help on functionality Hi Petter, that's not what i'm looking for. This function find all occurrences of a pattern. But i want to looking for all uses of a proper method of a class. For instance there is a class named A with a method named getAttributeX(). Then i want to find all lines of code that use exact this method of class A, neither using methods that sounds like getAttributeX (like: getAttributeXY or zzzgetAttributeX) nor methods that have the same name but are methods from another class (like: classB.getAttributeX()). Torsten Am Di, den 10.02.2004 schrieb Petter Måhlén um 09:59: Hi, Take a look at the JDE-Find-Expression menu alternative. It's also described in the user's guide (under Searching Source Code), and is nearly what you are looking for, I think. / Petter -Original Message- From: Torsten Geise [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2004 08:29 To: [EMAIL PROTECTED] Subject: request help on functionality Hi folks, is there a jde-function to find all usages of the function under the cursor or something like that. I'm using the official debian sid package jde 2.3.2. Thanks for any hints. Torsten. p.s.: thanks to paul and all other developer for this nice java ide and debugger. -- Mit freundlichen Grüßen EE information consultants AG Torsten Geise Bereich Architecture- and Solution Development Invalidenstraße 112, D-10115 Berlin Phone: +49-30-280 488 + 353 Fax: +49-(0)30-280488 28 [EMAIL PROTECTED] www.ee-consultants.de
RE: jde-2.3.3 error by jde-bug-evaluate-expression
The exception is throw by the Java side of JDEbug. It keeps a map of object id (269 in this case) and object reference in the process being debugged. The exception indicates that it cannot find the object with reference 269. I haven't looked at the 2.3.3 code, but if I remember right, in previous versions, JDEbug never cleaned out the object store. I would say that the most likely sources of the problem are: - the elisp side of JDEbug is using an invalid object ID (due to a bug), or - the Java side of JDEbug is nowadays cleaning out the object store, and the object in question has been cleaned out from the Java side but not the elisp side (meaning there is some bug in the cleaning out of objects). More questions in addition to what Andrew asked: does this happen immediately and always for the same object? Or do you have to run the debugger for some time first? Does it matter which program you are debugging? / Petter -Original Message- From: Andrew Hyatt [mailto:[EMAIL PROTECTED] Sent: den 26 januari 2004 19:32 To: Harald Maier Cc: Andrew Hyatt; [EMAIL PROTECTED] Subject: Re: jde-2.3.3 error by jde-bug-evaluate-expression What sort of thing are you trying to evaluate? Perhaps the bug is that the evaluation returns null (legitimately, perhaps) and throws an error incorrectly? Or perhaps a variable has gone out of scope and you are trying to evaluate it? Harald Maier [EMAIL PROTECTED] writes: Andrew Hyatt [EMAIL PROTECTED] writes: Does it ask for an expression to evaluate first? Yes, it asks for an expression and afterwards the above error is signaled. When I evaluate 'jde-bug-evaluate-expression' in a JDEbug session I get the following error: , | Error: cannot get object 269. | Reason: Exception during command execution: jde.debugger.JDEException: No such object exists. | eieio-oref: Wrong type argument: (or object-p class-p), nil ` Harald
RE: Problem with implement-interface wizard
Hi, The error you're getting is from the Java side of the JDE, whereas it is the elisp side of the JDE that figured out the full class name. It could be that the Java code can't find it because at the time the beanshell process was started, the interface was not on the classpath. In that case, killing the *bsh* window and trying again might work. Or it could be something else, but it's hard to tell without a bit more information. It's best to use the submit problem report feature if you have a problem, because that will give the experts on this list all the information they need. About your make problem, it's something I've seen before, which was either a configuration error or a bug that has now been solved. Again, the submit problem report would have given some more relevant information. You should know that the 'cd' in the compile window is not a true cd, it's just something that Emacs outputs into the buffer to indicate which directory it is attempting to compile from. Under some circumstance there was a mismatch between the two, which seems to describe your situation. / Petter -Original Message- From: Charles Sutton [mailto:[EMAIL PROTECTED] Sent: den 15 september 2003 23:18 To: [EMAIL PROTECTED] Subject: Problem with implement-interface wizard I was trying to use the implement-interface wizard, which just looks awesome. So I went to my class, and did C-c C-v i The minibuffer read Interface name: and I entered DiscreteDistribution which is on my classpath and sourcepath. The response I got was Error: could not find interface named: edu.umass.cs.mallet.users.casutton.mrf.DiscreteDistribution. Note: name must be qualified. To which I thought: uh... if it couldn't find the interface, how did it figure out the fully-qualified name? Any help would be appreciated! Charles -- Charles Sutton University of Massachusetts, Amherst [EMAIL PROTECTED] URL: http://www.cs.umass.edu/~casutton/
RE: [work] How can JDEbug evaluate expression be extended?
Hi, I think this is not particularly easy to do. The steps that are needed on the Java side are: 1. Create a new command object (jde.debugger.command.X) - piece of cake 2. Add it to the DebugCommandFactory list of prototypes - piece of cake 3. The hard part: make it do what you want. It's easy to use the list of StackFrame:s to figure out the value of a variable (see the GetLocals command), but it's quite hard to simulate execution of a function call in a detailed way. I am not at all sure how best to execute a call that could involve access to global variables, synchronization, etc. On top of that, there is the fact that you need to execute the call inside the debuggee VM, not the debugger VM, to ensure that class loading, etc., is all done in the same way. And normally, the debugee VM will be suspended by the debugger when stepping through the code, so I think you'd have to create a new thread with the same context as the current one and execute your call in that scope. It seems to quickly run out of hand here. I tried looking a bit at the JDI interface, but I couldn't see any way to do step 3. I didn't spend a lot of time on it, but it may be something that is not well supported at this level at least. Best regards, Petter -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: den 1 september 2003 04:37 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [work] How can JDEbug evaluate expression be extended? Jeff VanBaalen writes: Does anyone have an extension for the JDEbug Evaluate Expression command that enables one to examine the result of calling a method on some variable in the current context? If not, can anyone give me some hints on how hard this would be to do and how to do it? Its been a while, but I have hacked elisp before. Hi Jeff, This would require work on the Java side of JDEbug, not the Lisp side. You would have to enhance JDEbug's rather primitive expression interpreter to parse and evaluate method expressions. Paul
RE: Source not found while debugging
Hi, You could try setting jde-sourcepath, that should improve the chances of finding the correct source file. But as you say, the class name is weird. Are you hitting a breakpoint, or stepping, or what are you doing when this happens? / Petter -Original Message- From: Rodrigo de Salvo Braz [mailto:[EMAIL PROTECTED] Sent: den 16 mars 2003 00:05 To: [EMAIL PROTECTED] Subject: Source not found while debugging Hello, When debugging with JDE in Emacs 21.2 under Cygwin under Windows XP, I get the following message: Cannot find ncsa.rsb.ITR..TutoringSession source. Enter path: ~/dev/java The default path is the correct one. What is going wrong here? The only thing that seems suspicious is the .. right after ITR in the class name. Does it have to do with the problem? Any ideas on how to fix it? My .emacs is below (the JDE related part is the last portion). Thanks in advance.
RE: Bug Report
I'm not an elisp expert, but that looks pretty weird to me. First of all, where does c:/ant/bin/ant.bat come from? It's not in your environment anywhere according to the error report, and it's not anywhere in the JDE 2.3.2 code as far as I can tell. Also, I don't see why the actual error (not being able to find C:\\WINDOWS\\system32\\cmd.exe;c:\\wget) should happen - there's no reason to tuck C:\\wget onto the the string for launching the shell. Are there any strange settings in your init.el or prj.el files? I guess it's remotely possible that the compilation into .elc files has failed somehow. If Javier or somebody doesn't have a better idea, maybe you could try deleting them and trying again? / Petter
RE: Two useful key bindings for jde mode
Have you taken a look at camelCase? That resolves the same problem, but in a more generic way. It means that M-f, M-b, M-d, M-c, etc., treat current, Buffer and Position in your example as separate words. Really nice! / Petter http://www.hotdispatch.com/view-ip-requester?ID=14317280 -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: den 1 mars 2003 10:40 To: [EMAIL PROTECTED] Subject: Two useful key bindings for jde mode Folks, I thought you might find these useful. The idea is that when you are changing the name of a variable from say bufferPosition to currentBufferPosition using the default M-c binding (after inserting current) is useless because you will get currentBufferposition. With the following binding you will get currentBufferPosition. (define-key jde-mode-map [(meta c)] '(lambda () (interactive) (if (memq (get-char-property (point) 'face) '(font-lock-type-face font-lock-variable-name-face font-lock-function-name-face)) (upcase-region (point) (1+ (point))) (capitalize-word 1) ) )) The idea is that when you are changing the name of a variable from say currentBufferPosition to bufferPosition using the default M-l binding (after deleting current) is useless because you will get bufferposition. With the following binding you will get bufferPosition. (define-key jde-mode-map [(meta l)] '(lambda () (interactive) (if (memq (get-char-property (point) 'face) '(font-lock-type-face font-lock-function-name-face)) (downcase-region (point) (1+ (point))) (downcase-word 1) ) )) enjoy, sandip
RE: BeanShell can't find my class (jde-import-find-and-import)
Hm, it seems that your definition of jde-global-classpath is a bit weird: '(jde-global-classpath (quote ($CLASSPATH ~/wgen/eclipse-workspace/mclass/ampNG/build/classes ~/wgen/eclipse-workspace/mclass/javaserver/build/classes))) The quotes are in the wrong places, it should probably be '(jde-global-classpath (quote ($CLASSPATH ~/wgen/eclipse-workspace/mclass/ampNG/build/classes ~/wgen/eclipse-workspace/mclass/javaserver/build/classes))) Try changing it and see if it helps. Did you use customize-variable to set the value? It is definitely preferable to do so rather than manually editing the prj.el or .emacs. I'm also not 100% sure about including $CLASSPATH in jde-global-classpath, that might not give the result you are after. / Petter -Original Message- From: otisg [mailto:[EMAIL PROTECTED] Sent: den 28 februari 2003 21:32 To: [EMAIL PROTECTED] Subject: BeanShell can't find my class (jde-import-find-and-import) Hello, I am trying to use JDE's jde-import-find-and-import. Unfortunately, JDE/BeanShell cannot find any class I specify, and therefore JDE cannot insert the import statement. In my code I have: Bar bar = new Bar(); The focus is on Foo when I invoke jde-import-find-and-import. BeanShell starts and includes this in -classpath argument: -classpath ~/wgen/eclipse-workspace/mclass/ampNG/build/classes This is the directory where Bar class is: ~/wgen/eclipse-workspace/mclass/ampNG/build/classes/foo/Bar.class So how come BeanShell cannot find it? Where is it looking for my class? Thank you, Otis P.S. I have the following JDE variables defined: '(jde-global-classpath (quote ($CLASSPATH ~/wgen/eclipse-workspace/mclass/ampNG/build/classes ~/wgen/eclipse-workspace/mclass/javaserver/build/classes))) '(jde-sourcepath (quote (~/wgen/eclipse-workspace/mclass/javaserver/src/java ~/wgen/eclipse-workspace/mclass/javaserver/web/src/java ~/wgen/eclipse-workspace/mclass/amp/web/src/java ~/wgen/eclipse-workspace/mclass/ampNG/web/src/java ~/wgen/eclipse-workspace/mclass/reading/src/java ~/wgen/eclipse-workspace/mclass/reading/web/src/java ~/wgen/eclipse-workspace/mclass/rigby/src/java ~/wgen/eclipse-workspace/mclass/rigby/web/src/java))) Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag
RE: JDEE plugins (was JUCI)
I second those sentiments and that motion. / Petter -Original Message- From: Mark Pollack [mailto:[EMAIL PROTECTED]] Sent: den 19 februari 2003 02:01 To: Paul Kinnucan; Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Hi, Just my two cents, I'm a lisp-wimp as I am sure are many of the users of JDEE, but a good Java programmer. If there was some way that I could write JDEE extensions in Java for at least some subset of plug-in functionality that would be great since I never seem to find the time to really learn lisp. I realize it might be too much to accommodate us lisp-wimps, but just keep it in mind if it turns out to be not such a big deal to go in this direction. Cheers, Mark -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 5:25 PM To: Nascif Abousalh-Neto Cc: Paul Kinnucan; [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Nascif Abousalh-Neto writes: Sounds like a great idea! I would volunteer to re-write the Jalopy (http://jalopy.sourceforge.net/) integration package I put together. I could also take a stab at a re-write for the integration package for PMD (http://pmd.sourceforge.net/). Those Elisp-Java packages have an awful lot of code in common, and it would be really nice to create a standard way to create them - specially the bit about a standard way to integrate with the BeanShell. Great. I assume that you will conform to the directory structure that I proposed and provide the package as a jar or lisp file. Please let me know if you intend to implement any other suggestions, e.g., Ole's idea of a standard entry point: lisp/plugin.el I would like to suggest also a standard way for those packages to present their output. A lot of them generate warnings or errors that go very well in a compilation mode buffer. I think this behavior can be abstracted as well. beanshell.el previously contained an unfinished eieio class that provides a compilation-style buffer for BeanShell-based applications. My idea is that the compile server and the ant package and any other Beanshell based applications that needed compilation-like buffers could specialize and instantiate this class. I deleted it in my last update but I think I'll revive it. - Paul Regards, Nascif -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 3:27 PM To: [EMAIL PROTECTED] Subject: JDEE plugins (was JUCI) Hi Nick, I am posting my response to your idea of JUCI-based plugins to the JDEE list because I am interestedin getting other people's input on this idea. - Paul Nick Sieger writes: [snip] Do you have a long-term vision for any standard interface or API for integrating user-developed components? Right now, most of the user-submitted code seems to be little snippets here and there. It would be cool if people could share pieces of code in a manner that they could just drop a file or a jar archive in a well-known place in the JDEE installation filesystem and the JDEE would auto-detect the new component, load it up and make the code available. I haven't really thought about it. One thing that occurs to me is that I could add a subdirectory called plugins to the JDEE tree where users could put an entire hybrid Java/Lisp plugin, i.e., the JDEE tree would look like this: JDEEroot lisp java doc plugins plugin1 lisp java scripts classes src lib doc javadoc design help info html src plugin2 ... The JDEE would load/eval the files in the lisp directory and add the classes directory and the jar files in the lib directory to the BeanShell's classpath. I could also add a Plugins submenu to the JDEE menu and define a JDEE Lisp function that plugins could call to add a command or submenu of commands to the Plugins directory. This solution is not as convenient as your idea of a single jar file. But remember that one of the principles of freeware is to include the source. Perhaps the first time the JDEE detects a jar or zip file at the top level of the Plugins directory it could unpack it, assuming that its contents are structured as I proposed. This would provide the ease of distribution and installation that you have in mind with my objective of ensuring that plugins are complete packages with Lisp, Java, design and API doc, and user doc (i.e., html and/or info help files). How does this
RE: copile errors (emacs 21.2, linux, jde)
Hm, my guess is that the problem is that JDE doesn't find the correct JDK directory: # ERRORS # cd /home/rktmb/programation/java/ /:/bin/java -Xdebug -Xrunjdwp:transport=dt_socket,address=,server=y,suspend=n Banque Can't exec program: /:/bin/java Process Banque exited abnormally with code 1 # /:/bin/java is not a very good path. I would take a look at the following: - the JAVA_HOME and JAVA_VERSION environment variables - the documentation for jde-get-jdk-dir (use M-x describe-function) That should probably solve your problem. / Petter
RE: Fail to generate javadoc
Hi, I think that the missing file or directory is not the executable, but the place where JDEE tries to create the documentation. It normally defaults to some path/JavaDoc. So it seems to be unable to find or create that directory. If you are using Cygwin, it could be due to some path conversion problem. / Petter -Original Message- From: Mei Wu [mailto:[EMAIL PROTECTED]] Sent: den 29 januari 2003 10:05 To: [EMAIL PROTECTED] Subject: Fail to generate javadoc Hi, In my first attempt on jdee, I failed to generate javadoc for a java file, I have customized the Jde Javadoc Command Path, but still it tries to find the JavaDoc in the current file dir, the error it gives is : no such file or directory, /home/meiwu/java/demo/jfc/FileChooserDemo/src/JavaDoc Surely it should be javadoc, not JavaDoc, how could it try to use JavaDoc ? Could anyone give me a clue ? Thanks Mei
RE: Windows 2000 service pack 3 problem with Compiling run Java program
Title: Message
Hi,
What
you should do is type "M-x describe-function [RET] jde-get-jdk-dir" in Emacs.
That will show you documentation that describes exactly how to solve your
problem.
Best
of luck,
Petter
-Original Message-From: Takeshi Go
[mailto:[EMAIL PROTECTED]] Sent: den 26 januari 2003
16:22To: [EMAIL PROTECTED]Subject: Windows 2000 service
pack 3 problem with Compiling run Java program
hi, i am a noob
Problem: After i
patched the Windows 2000 Professional to Service Pack 3 or WinXP with Service
pack1 the program no longer compile or executes
any idea??it said that it can not find theJDK
directory
it said it wants to me to
find jde-get-jdk-dir
but i have searched all the
option, no luck finding it
this is just a testing program to see if emacs+JDE
runs running J2SDK 1.4.1_01 J2SDK
Path: ===
C:/j2sdk1.4.1_01 File Path of Hello.java:
D:/Multi-level inventory
system/hello.java setup: ==
.emac.d and .emacs and .emac~ are in C:\ emacs-21.2 is in
D:\ Host Platform: Windows 2000
Professional JDEE Version: JDEE 2.3.2 Emacs Version:
21.2 .emacs file ===
(custom-set-variables ;; custom-set-variables was added
by Custom -- don't edit or cut/paste it! ;; Your init
file should contain only one such instance. '(case-fold-search
t) '(current-language-environment "Latin-1")
'(default-input-method "latin-1-prefix")
'(global-font-lock-mode t nil (font-lock)) '(show-paren-mode t
nil (paren)) '(transient-mark-mode t))
(custom-set-faces ;; custom-set-faces was added by
Custom -- don't edit or cut/paste it! ;; Your init file
should contain only one such instance. )
(add-to-list 'load-path
"c:/.emacs.d/jde-2.3.2/lisp") (add-to-list
'load-path "c:/.emacs.d/semantic-1.4beta14")
(add-to-list 'load-path
"c:/.emacs.d/speedbar-0.14beta4") (add-to-list
'load-path "c:/.emacs.d/elib-1.0") (add-to-list
'load-path "c:/.emacs.d/eieio-0.17beta4") (require
'jde) The Code i am
trying to run=== public class
hello{ public static void main (String []
args){
System.out.println("hello");
}}===
it said
can not find jdk's tools jar files (or equivalent). see
jde-get-jdk-dir
i have searched the mailing list, still dont know where to find this
option
i tried Mx jde-get-jdk-dir Ret
nothing happened...
help!!
RE: jde-global-classpath error
I think if anybody is going to be able to help you, you need to provide a lot more information. Use the JDE/Help/Submit Problem Report menu function. / Petter -Original Message- From: Jeba Bhaskaran [mailto:[EMAIL PROTECTED]] Sent: den 14 januari 2003 18:20 To: [EMAIL PROTECTED] Subject: jde-global-classpath error I am using jde-global-classpath variable. When compiling, JDE only uses the last part of the path. For example, C:\jars\test.jar comes out as -classpath C:/test.jar. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Importing in JDE - minor bug
Hi, I have a file with (at least) the following import statement: import java.util.*; If I then ask JDE to import java.util.List, a new statement will be added: import java.util.*; import java.util.List; The second statement is of course redundant. I think I have traced the problem to: (defun jde-import-strip-existing-imports (new-imports existing-imports) Exclude classes that have already been imported. (let (i n return-imports) (setq i 0) (setq n (length new-imports)) (while ( i n) ;;iterate through the new imports (let((new-import (nth i new-imports))) ;;Strip out those alreay there (when (not (find new-import existing-imports :test 'string=)) (setq return-imports (nconc (list new-import) return-imports (setq i(+ i 1))) ;;Return any that still exist return-imports)) The comparison test 'string= should probably be changed to a test that matches if: - there is an exact string match, or - if packagename.* is imported (but not if packagename.subpackage.* is imported) That should not be too hard to do with a regexp, I guess, but I am not sure how to actually do it. Any elisp-literate people out there who can solve it? / Petter
Interface implementation wizard - minor bug
Hi,
I am using an empty interface to indicate that a certain operation
(filtering) is possible on objects implementing it (much like the way
Cloneable works). The jde-wiz-implement-interface wizard doesn't support
this perfectly, since it adds 'implements Filterable' but doesn't
generate an import statement. It seems to be a problem in
jde.wiz.InterfaceFactory.process():
public void process(String name, boolean truncate)
throws ClassNotFoundException, NotAnInterfaceException
{
if (null == namefactory)
namefactory = new DefaultNameFactory();
Class aclass = Class.forName( name );
if (false == aclass.isInterface())
throw new NotAnInterfaceException(name);
registerImport(aclass); // --- Added
by Petter
Method[] methods = aclass.getMethods();
for (int i = 0; i methods.length; i++)
sortByDeclaringClass( new Signature( methods[i], this, truncate )
);
}
Without the flagged line, if there are no methods in the interface, the
interface class will not be imported. However, when I had found this, I
also found a second problem, which I cannot quite understand. I used a
test class like this:
==
public class IFTest {
} // IFTest
==
And a test interface (in a different package) like this:
==
package dbgtest;
public interface IF {
}// IF
==
When I have the IFTest.java buffer open and do a
jde-wiz-implement-interface and specify IF, the import statement is
correctly generated. However, I normally have
jde-import-auto-collapse-imports set to true, which means that the
import statement is immediately deleted! (the *Messages* buffer
indicates that an import is removed) In my real class, that doesn't
happen. I don't understand why, and I cannot quite understand the
jde-import-kill-extra-imports function, which I guess is the culprit.
Additionally, if I call jde-import-kill-extra-imports with the following
file, the import statement is correctly left in place:
==
import dbgtest.IF;
public class IFTest implements IF {
} // IFTest
==
I guess it might be something in the interplay between semantic and JDE
that is not working under some circumstances. In any case, I believe
that the first fix is correct, and probably the second problem is not
too serious.
Best regards,
Petter
Completion problem
Hi,
I have just switched to a new computer, in the process upgrading my
installation of JDE and the rest. I copied the old .emacs file, and have
already had to make some fixes to that to get things to work properly
with the JDEE, so maybe it's some kind of upgrade issue. Anyway, the
problem I am having is this:
1. I try to use jde-complete (through C-c C-v C-.) for an object whose
class has not been imported yet.
2. I get the message Could not find type of var Attempt to import Type?
(y or n). I choose 'y', and the response is a multiple options
(typically, a class with a name like Connection, which is available in a
lot of packages).
3. I select the right type, and the import statement is added.
4. Completion still doesn't work, and whenever I try to to jde-complete
again, the same thing happens, only when I choose 'y', I get the message
that the class has already been imported.
5. If I kill the current buffer and reopen it, completion works.
6. If I kill the beanshell without killing the current buffer, the same
problem still happens.
Note that the bug doesn't happen if either the class is already
imported, or if there is a single match when JDEE looks for the class to
import. Also, although this bug report is from 2.3.0, the behaviour in
2.3.1 is exactly the same.
Best regards,
Petter
Emacs : GNU Emacs 21.2.1 (i386-msvc-nt5.1.2600)
of 2002-03-19 on buffy
Package: JDE version 2.3.0
Required packages: semantic-1.4 eieio-0.17 speedbar-0.14beta4
current state:
==
(setq
jde-gen-session-bean-template '((jde-import-insert-imports-into-buffer
(list \javax.ejb.*\
\java.rmi.RemoteException\)) '
(jde-wiz-update-implements-clause
\SessionBean\) ' (jde-gen-method-signature \public\
\void\ \ejbActivate\ nil \RemoteException\ ) '
(if jde-gen-kr () 'n) \{\''n \}\''n 'n
(jde-gen-method-signature \public\ \void\
\ejbPassivate\ nil \RemoteException\ ) ' (if
jde-gen-kr () 'n) \{\''n \}\''n 'n
(jde-gen-method-signature \public\ \void\
\ejbRemove\ nil \RemoteException\ ) ' (if
jde-gen-kr () 'n) \{\''n \}\''n 'n
(jde-gen-method-signature \public\ \void\
\setSessionContext\ \SessionContext ctx\
\RemoteException\ ) ' (if jde-gen-kr () 'n)
\{\''n \}\''n 'n (jde-gen-method-signature \public\
\void\ \unsetSessionContext\ nil \RemoteException\
) ' (if jde-gen-kr () 'n) \{\''n \}\''n 'n ')
jde-gen-beep '((end-of-line) '
\Toolkit.getDefaultToolkit().beep();\''n')
jde-complete-signature-display '(Eldoc)
jde-project-name default
jde-which-method-format '([ jde-which-method-current ])
jde-run-classic-mode-vm nil
jde-complete-unique-method-names nil
jde-find-granularity '(Character)
jde-which-method-max-length 20
jde-javadoc-gen-nodeprecatedlist nil
jde-package-search-classpath-variables '(jde-compile-option-classpath
jde-global-classpath)
jde-imenu-include-classdef t
jde-javadoc-gen-link-online nil
jde-complete-display-result-type t
jde-gen-code-templates '((Get Set Pair . jde-gen-get-set)
(toString method . jde-gen-to-string-method)
(Action Listener . jde-gen-action-listener)
(Window Listener . jde-gen-window-listener)
(Mouse Listener . jde-gen-mouse-listener)
(Mouse Motion Listener .
jde-gen-mouse-motion-listener)
(Inner Class . jde-gen-inner-class)
(println . jde-gen-println) (beep .
jde-gen-beep)
(property change support .
jde-gen-property-change-support)
(EJB Entity Bean . jde-gen-entity-bean)
(EJB Session Bean . jde-gen-session-bean))
jde-gen-cflow-else '((if (jde-parse-comment-or-quoted-p) '(l
\else\)
'(l ' \else\ (if jde-gen-kr
jde-gen-conditional-padding-3''n)
\{\''n''r'n \}\ (if jde-gen-comments
'(l \ // end of else\)) ''n') ))
jde-jdk-registry nil
jde-javadoc-gen-destination-directory JavaDoc
jde-mode-line-format '(- mode-line-mule-info mode-line-modified
mode-line-frame-identification
mode-line-buffer-identification
global-mode-string
%[( mode-name mode-line-process
minor-mode-alist %n
)%]-- (line-number-mode L%l--)
(column-number-mode C%c--) (-3 . %p)
(jde-which-method-mode (--
jde-which-method-format --))
-%-)
jde-mode-abbreviations '((ab . abstract) (bo . boolean) (br .
break)
(by . byte) (byv . byvalue) (cas .
cast)
(ca . catch) (ch . char) (cl .
class)
RE: jde-wiz-implement-interface
Hmm. This seems to be a bug in jde.util.ClassPathZip.load():
void load() throws IOException {
ZipFile zipFile = new ZipFile(zipOrJar);
Enumeration enum = zipFile.entries();
while (enum.hasMoreElements()) {
ZipEntry zipEntry = (ZipEntry)enum.nextElement();
String current = zipEntry.getName();
if (current.toLowerCase().endsWith(.class)) {
current = current.substring(0, current.length() - 6);
current = current.replace('/', '.');
current = current.replace('\\', '.');
super.addClass(current);
}
}
setLoaded(true);
}
The inner-class .class file will be called class$innerClass.class, leading
to the problem Henrik describes, so maybe another substitution should be
added:
current = current.replace('$', '.');
My JDE installation is lagging behind, so I haven't tested it, but this
seems to make sense. If so, the same change should be made to
jde.util.ClassPathDir.addRecursively.
/ Petter
-Original Message-
From: Henrik Kjær [mailto:[EMAIL PROTECTED]]
Sent: den 29 november 2002 14:51
To: [EMAIL PROTECTED]
Subject: jde-wiz-implement-interface
There is a bug in the interface wizard - it insert $ when the interface to
be implemented
uses inner classes.
Example:
My interface -
import path.Class;
public interface MyInterface {
void myMethod(Class.innerClass)
}
will result in
import path.Class$innerClass;
MyInterfaceImpl implement MyInterface {
public void(Class$innerClass class$innerClass) {
}
Henrik Kjær
RE: Repost: where is 'semantic-load' to be found?
It looks like you're trying to use an invalid semantic version. From the release notes for 2.2.8: JDE 2.2.8 *** * PLEASE READ * *** * * * This release requires semantic 1.4beta5 (or later), * * speedbar 0.13 (or later), and eieio-0.16 (or later, * * except eieio-0.17beta1). You can obtain all three * * packages at http://cedet.sourceforge.net* * * * Note: This release does not work with eieio-0.17beta1, but * * it does work with eieio-0.17beta2. * * * * 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://sunsite.dk/jde/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.* * * *** / Petter -Original Message- From: James Sinnamon [mailto:[EMAIL PROTECTED]] Sent: den 16 mars 2002 14:46 To: [EMAIL PROTECTED] Subject: Repost: where is 'semantic-load' to be found? Dear JDE users, Can anyone tell me where the file semantic-load.el might be found? jde.el fails on the statement, (require 'semantic-load). I cannot find `semantic-load.el' or 'sematic-load.elc' on my emacs installation or in any of the packages required by jde: semantic, speedbar, eieio, or e-lib. Would anyone be able to say where I should be able to find the file `semantic-load.el', or have I misunderstood the meaning of (require 'semantic-load). TIA James Sinnamon On Tuesday 05 March 2002 1:50 pm, James Sinnamon wrote: Couls anyone out there please help someone who has not used emacs for a while? I have installed all of the required files in ~/emacs/site/: lrwxrwxrwx1 sinnamon upside 11 Mar 5 10:37 eieio - eieio-0.16/ drwxr-xr-x2 sinnamon upside 1024 Feb 20 2001 eieio-0.16 lrwxrwxrwx1 sinnamon upside 9 Mar 5 10:37 elib - elib-1.0/ drwxr-xr-x2 sinnamon upside 1024 Dec 11 1995 elib-1.0 lrwxrwxrwx1 sinnamon upside 10 Mar 5 10:37 jde - jde-2.2.8/ drwxr-xr-x5 sinnamon upside 1024 Aug 24 2001 jde-2.2.8 lrwxrwxrwx1 sinnamon upside 15 Mar 5 10:38 semantic - semantic-1.3.3/ drwxr-xr-x2 sinnamon upside 1024 Mar 5 11:46 semantic-1.3.3 lrwxrwxrwx1 sinnamon upside 15 Mar 5 10:37 speedbar - speedbar-0.13a/ drwxr-xr-x2 sinnamon upside 1024 Oct 9 2000 speedbar-0.13a My ~/.emacs includes (add-to-list 'load-path (expand-file-name ~/emacs/site/jde/lisp)) (add-to-list 'load-path (expand-file-name ~/emacs/site/semantic)) (add-to-list 'load-path (expand-file-name ~/emacs/site/speedbar)) (add-to-list 'load-path (expand-file-name ~/emacs/site/elib)) (add-to-list 'load-path (expand-file-name ~/emacs/site/eieio)) The value of load-path is: (/upside/home/sinnamon/emacs/site/eieio /upside/home/sinnamon/emacs/site/elib /upside/home/sinnamon/emacs/site/speedbar /upside/home/sinnamon/emacs/site/semantic /upside/home/sinnamon/emacs/site/jde/lisp /usr/share/emacs/site-lisp/auctex/ /usr/share/emacs/20.3/site-lisp /usr/share/emacs/site-lisp /usr/share/emacs/20.3/leim /usr/share/emacs/20.3/lisp /usr/share/emacs/20.3/lisp/textmodes /usr/share/emacs/20.3/lisp/progmodes /usr/share/emacs/20.3/lisp/play /usr/share/emacs/20.3/lisp/mail /usr/share/emacs/20.3/lisp/language /usr/share/emacs/20.3/lisp/international /usr/share/emacs/20.3/lisp/gnus /usr/share/emacs/20.3/lisp/emulation /usr/share/emacs/20.3/lisp/emacs-lisp /usr/share/emacs/20.3/lisp/calendar) When I start GNU emacs I get the message: Error in init file: File error: Cannot open load file, semantic-load Alos, for what its worth, when attempt to byte comile semantic, I get the error message: While compiling toplevel forms in file /upside/home/sinnamon/emacs/site/semantic-1.3.3/semantic-sb.el: !! Symbol's value as variable is void ((c-frame)) While compiling the end of the data in file /upside/home/sinnamon/emacs/site/semantic-1.3.3/working.el: ** the function frame-property is not known to be defined. TIA James
RE: navigation question
You're right, I realised I didn't read the question fully. But then I'd already sent my answer. I seem to remember that the feature you're describing has been discussed previously though, and that Paul asked for somebody with the time and skills to implement it to go ahead. I'm not that guy, but I also think it would be really nice. / Petter -Original Message- From: Laurent Mirguet [mailto:[EMAIL PROTECTED]] Sent: den 14 mars 2002 10:48 To: Petter Måhlén Cc: cb Turner; [EMAIL PROTECTED] Subject: Re: navigation question Petter Måhlén wrote: C-cC-vC-y does just that, with a couple of restrictions: - the class in question must be compiled, and the .class file on the jde-global-classpath - the source file must be found on jde-db-source-directories - there's no stack other than the normal Emacs buffer navigation Maybe I am wrong, but it seems to me that C-c C-v C-y doesn't jump to the definition of whatever is under the cursor. The cursor needs to be over a class. But I would like to be able to do the same with a method : JDE would analyse on which type of object the method is applied, open the class, and point on the method automaticaly. The same with attributes. It would be quite nice. ;-) Laurent
RE: problem with jdebug
Hm, well, that doesn't give me any good clues, I'm afraid. What is going wrong is that the Emacs side of JDEbug doesn't connect to the Java side, so the Java side times out. For your further troubleshooting, the steps are: 1. Emacs launches the Java part of the debugger 2. The Java part tells Emacs to connect to a specific port (the dbo-command-result 1 59464 line in *JDEbug*) 3. Emacs is supposed to connect to that port, getting sockets to connect to stdin, stdout and stderr of the debuggee process. I know that some fix to that connection process was made, and it could be that it was later than 2.2.8. There are only two things I can suggest: - try upgrading to 2.2.9beta8, it works really well in general, and may contain a fix to your problem. - try to figure out why such a high port number as 59464 is used. That seems kind of suspicious, although it shouldn't be a problem in itself. / Petter -Original Message- From: Thomas Borup [mailto:[EMAIL PROTECTED]] Sent: den 6 mars 2002 19:21 To: [EMAIL PROTECTED] Subject: Re: problem with jdebug Petter Mahlen wrote: Would love to help, but you need to supply a lot more information than that. Include the full *JDEbug* buffer at least, and preferably use the 'submit bug report' function. Also, make sure to indicate operating system versions, etc. / Petter -Original Message- From: Thomas Borup [mailto:[EMAIL PROTECTED]] Sent: den 6 mars 2002 18:41 To: [EMAIL PROTECTED] Subject: problem with jdebug Hi, I have just installed jde 2.2.8, everything works fine except the debugger. Can anybody tell me the reason why I receive these messages when I try to debug a simple program following the instructions from the jdebug-ug documentation. *Debug* (jde-dbo-error 2 Gave up waiting for Emacs to connect to SIO port: 59275) *Messages No response to command 1. (process = 1; timeout = 30 sec.) Thanks, Thomas OK - I have attached the result from jde-submit-problem-report. It includes the full *JDEbug* buffer. /TB
RE: How to Customize Indentation?
It sounds as if you're trying to change the way that Emacs presents the code without actually changing it. If so, you could try customising tab-width. Otherwise, I like to do 'untabify' to only use spaces throughout the code, that saves a lot of problems I think. / Petter -Original Message- From: Jonathan Meeks [mailto:[EMAIL PROTECTED]] Sent: den 28 februari 2002 05:01 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to Customize Indentation? Someone posted a customization to cc-mode, which jdee uses. It was about two weeks ago (there's an archive of the jdee mailing list on jdee's site). I am using that customization, and it works very well. HTH, Jonathan Meeks From: [EMAIL PROTECTED] (Ping Liang) Subject: How to Customize Indentation? Date: Wed, 27 Feb 2002 18:55:52 -0500 I am working on java source codes that were written by using other ide tools. The original developer just set the tab to 4 chars wide (still a tab) and format the code accordingly. Now it is my turn to read the code, and I am using emacs, it is a mess! I am wondering anybody has worked out a good solution to this. Basically, I want to have the ability to view others code in his/her own format/indentation and contribute to it in the same format/indentation. On the other hand, what I write should be reasonably readable by others using other editing tools. Any hints are greatly appreciated. Ping Liang -- __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
RE: jde2.2.9beta.. error on .emacs loading..
Hi, I'm not an elisp expert, but based on the many mails on this list about the subject, this looks like a byte-compilation problem. So I would try this: 1. remove all .elc files for JDE and related packages (eieio, etc) 2. try again 3. if it works but feels too slow, byte-compile with jde-compile-jde (doesn't work for me in 2.2.9beta8) or the makefiles supplied with the packages. / Petter -Original Message- From: eugene kim [mailto:[EMAIL PROTECTED]] Sent: den 16 februari 2002 23:19 To: [EMAIL PROTECTED] Subject: jde2.2.9beta.. error on .emacs loading.. hello.. what's the problem here? -- --- Signaling: (cl-assertion-failed (typep listener jde-db-listener)) signal(cl-assertion-failed ((typep listener jde-db-listener))) (or (typep listener jde-db-listener) (signal (quote cl-assertion-failed) (list ...))) ) (progn (or (typep listener jde-db-listener) (signal ... ...)) nil) ) (assert (typep listener jde-db-listener)) ) jde-db-debugger([object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #0 [object jde-jdb-cmd-launch launch unbound #0] [object jde-jdb-cmd-run run unbound #0] [object jde-jdb-cmd-cont cont unbound #0] [object jde-jdb-cmd-quit jdb quit unbound #0] [object jde-jdb-cmd-step-over jdb step-over cmd unbound #0] [object jde-jdb-cmd-step-into jdb step-into cmd unbound #0] [object jde-jdb-cmd-up jdb up cmd unbound #0] [object jde-jdb-cmd-down jdb down cmd unbound #0] [object jde-jdb-cmd-where jdb where cmd unbound #0] [object jde-jdb-cmd-set-breakpoint jdb set breakpoint unbound #0 unbound] [object jde-jdb-cmd-clear-breakpoint jdb clear breakpoint unbound #0 unbound]] nil unbound jdb jdb] [object jde-jdb-breakpoint-listener jdb breakpoint listener [object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #1 ... ... ... ... ... ... ... ... ... ... ...] nil unbound jdb jdb] ^.*: thread=.*, \\(\\(.*[.]\\)*\\)\\([^$]*\\)\\($.*\\)*[.].+(), line=\\([0-9]*\\), 3 5 ^Breakpoint hit: .*(pc \\([0-9]*\\)) ]) apply(jde-db-debugger ([object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #1 ... ... ... ... ... ... ... ... ... ... ...] nil unbound jdb jdb] [object jde-jdb-breakpoint-listener jdb breakpoint listener [object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil ... nil unbound jdb jdb] ^.*: thread=.*, \\(\\(.*[.]\\)*\\)\\([^$]*\\)\\($.*\\)*[.].+(), line=\\([0-9]*\\), 3 5 ^Breakpoint hit: .*(pc \\([0-9]*\\)) ])) eieio-generic-call(jde-db-add-listener ([object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #1 ... ... ... ... ... ... ... ... ... ... ...] nil unbound jdb jdb] [object jde-jdb-breakpoint-listener jdb breakpoint listener [object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil ... nil unbound jdb jdb] ^.*: thread=.*, \\(\\(.*[.]\\)*\\)\\([^$]*\\)\\($.*\\)*[.].+(), line=\\([0-9]*\\), 3 5 ^Breakpoint hit: .*(pc \\([0-9]*\\)) ])) jde-db-add-listener([object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #0 [object jde-jdb-cmd-launch launch unbound #0] [object jde-jdb-cmd-run run unbound #0] [object jde-jdb-cmd-cont cont unbound #0] [object jde-jdb-cmd-quit jdb quit unbound #0] [object jde-jdb-cmd-step-over jdb step-over cmd unbound #0] [object jde-jdb-cmd-step-into jdb step-into cmd unbound #0] [object jde-jdb-cmd-up jdb up cmd unbound #0] [object jde-jdb-cmd-down jdb down cmd unbound #0] [object jde-jdb-cmd-where jdb where cmd unbound #0] [object jde-jdb-cmd-set-breakpoint jdb set breakpoint unbound #0 unbound] [object jde-jdb-cmd-clear-breakpoint jdb clear breakpoint unbound #0 unbound]] nil unbound jdb jdb] [object jde-jdb-breakpoint-listener jdb breakpoint listener [object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #1 ... ... ... ... ... ... ... ... ... ... ...] nil unbound jdb jdb] ^.*: thread=.*, \\(\\(.*[.]\\)*\\)\\([^$]*\\)\\($.*\\)*[.].+(), line=\\([0-9]*\\), 3 5 ^Breakpoint hit: .*(pc \\([0-9]*\\)) ]) jde-db-jdb([object jde-db-jpda-jdb jpda jdb jdb Java Debugger unbound unbound nil unbound nil [object jde-jdb-cmd-set jdb commands #0 [object jde-jdb-cmd-launch launch unbound #0] [object jde-jdb-cmd-run run unbound #0] [object jde-jdb-cmd-cont cont unbound #0] [object jde-jdb-cmd-quit jdb quit unbound #0] [object jde-jdb-cmd-step-over jdb step-over cmd unbound #0] [object jde-jdb-cmd-step-into jdb step-into cmd unbound #0] [object jde-jdb-cmd-up jdb up cmd unbound #0] [object jde-jdb-cmd-down jdb down cmd unbound #0] [object jde-jdb-cmd-where jdb where
RE: Needs help to get JDEE working...
Hi, Do you want to use JDK 1.1 when compiling? The error message says that you can't use the 'selected' debug info option. JDE has determined that you are using JDK 1.1, so if that's unintentional, you should check the $JAVA_VERSION environment variable and the jde-jdk customization variable. You may also want to look at the jde-compile-option-debug customization variable to choose some other option for debug info than 'selected'. Best of luck, Petter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Nandan Chandrakant Joshi Sent: den 1 februari 2002 04:45 To: [EMAIL PROTECTED] Subject: Re: Needs help to get JDEE working... Hallo, thank u very much that u have provided me the .emacs file. I found the error. I was using latest version of Semantic. and thanked God that I found it as I have given the name to the installed folders according to beta releases. And now I installed quite older Semantic and now I can get JDE Menu as I wanted and even my font-lock error has be solved. Thanx a lot. But I've got one more problem, when I try to compile my java files, I get error as 'jde-compile-javac-11: JDK 1.1 version of javac does not support selected debug info.' Well, I dunno what exactly it wanna say, as here is the excerpt from my new .gnu-emacs file: JDE custom set variables;;; (custom-set-variables ;; custom-set-variables was added by Custom -- don't edit or cut/paste it! ;; Your init file should contain only one such instance. '(delete-selection-mode nil nil (delsel)) '(jde-bug-jdk-directory /usr/lib/j2sdk1.4.0) '(jde-bug-jpda-directory /usr/lib/j2sdk1.4.0) '(jde-bug-local-variables t) '(jde-bug-vm-includes-jpda-p t) '(jde-db-source-directories (quote (./ /usr/lib/j2sdk1.4.0/src))) '(jde-debugger (quote (JDEbug))) '(jde-global-classpath (quote ($CLASSPATH ./))) '(scroll-bar-mode (quote right))) (custom-set-faces ;; custom-set-faces was added by Custom -- don't edit or cut/paste it! ;; Your init file should contain only one such instance. ) Well, I have all those files in that particular directory that I had entered there. But what could be wrong. I'd be glad to have any help from u in this case. Thanx in advance again!!! nandan -- *** Not dead which eternal lie stranger eons Death my die drain you of your sanity face The Thing That Should Not Be. it's not who you are it's who you know others lives are the basis of your own burn your bridges build them back with wealth judge not lest ye be judged yourself ||| On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows 95 or better'. So I installed Linux.' ||| Nandan Chandrakant Joshi [EMAIL PROTECTED] [EMAIL PROTECTED] Tel.Nr.- +49 511 3708570 Mobile Nr.- +49 160 5436882
RE: Auto import-collapse
Yes, the JDE needs reflection to determine the fully qualified name of the class to be imported. Reflection is possible only with compiled classes. Actually, as far as I can tell, the fully qualified name returned by jde.util.JdeUtilities.getQualifiedName appears to only be determined by the path from the root of each class path entry, plus the name of the .class file. That is: - the class path contains /dir - a file is called /dir/pkg/subpkg/List.class - the fully qualified name will be given as pkg.subpkg.List And I think that that algorithm would make quite as much sense for uncompiled source files somewhere in jde-db-source-directories. You wouldn't be able to get to inner classes, but I don't think that that is an issue. I have looked briefly at side effects, and I think the following behaviours would also be changed: - jde-open-class-source could open uncompiled class files (which I think is good) - jde-parse-select-qualified-class-name would also display uncompiled source files, which I am not sure what it means - jde-wiz-implement-interface-internal, jde-wiz-implement-event-source-internal and jde-wiz-extend-abstract-class-internal would not work if one tried to implement an interface/abstract class defined in an uncompiled source file. So to handle that, one would probably have to change the interface to restrict searching to only compiled classes. Maybe Eric Friedman, who wrote the code, could correct me if I'm wrong. For me at least, it would be useful to be able to import a class that I haven't yet compiled. If others think so, I could look into modifying the Java code so that it also looks for source files and not just class files. / Petter
RE: Auto import-collapse
Hi, As far as I can tell, jde-import-find-and-import also only works with already compiled classes. Unless I misunderstand you, when you say that class - I mean the class to be imported has to be compiled already. I actually got a bit confused by this today, when the system was unable to find a new class that I hadn't compiled yet. Is there a compelling reason to only allow imports of already compiled classes? The relevant place in the code appears to be jde.util.ClassPathDir, method addRecursively, where there is a check that the file name endsWith(.class). Would it be possible to just change that to .java? I guess it would be problematic for those who separate .class and .java files, but maybe the jde-db-source-directories path could be searched as well. If that's not possible, maybe the imports window could notify the user that if the class you were looking for is missing, you should know that only compiled classes can be auto-imported. That could perhaps save some confusion. / Petter (By the way, Paul, I couldn't find anywhere that jde.wizards.ImportWizard was used, so maybe that could be removed?) -Original Message- From: Nick Sieger [mailto:[EMAIL PROTECTED]] Sent: den 24 januari 2002 19:45 To: 'Sandip Chitale'; 'Matthew Rippa' Cc: 'JDE Mailing List' Subject: RE: Auto import-collapse There was some discussion on this some months ago. In fact I have written a BCEL based tool to do the expansion of import.I think Nick Sieger had started a JDEE extension to do that kind of stuff using my tool.I do not know what is the current state of that though. Does anyone have any clue ? Is it part of JDEE now ? Check the following threads - http://www.mail-archive.com/jde@sunsite.dk/msg01022.html http://www.mail-archive.com/jde@sunsite.dk/msg01127.html -regards, sandip Unfortunately, the auto-importer I wrote only works if you already have a compiled version of that class. It appears that Matt needs to do this before the first compile. So there needs to be some parsing of symbols in the java file in order to automate the import of all unqualified symbols. Unfortunately, semantic 1.x does not parse method bodies so there would have to be another way to do it. Personally, I use `next-error' in tandem with `jde-import-find-and-import' quite a bit. Best, /Nick -Original Message- From: Matthew Rippa [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 11:14 AM To: JDE Mailing List Subject: Auto import-collapse HI, I know this is just being lazy, but is there a way, after just witing a class, to have the JDEE import and collapse all necessary classes? I seem to be spending considerable time using C-c C-v C-z on each class name. --although I coudn't live without that feature! 8-) Thanks for any help, -Matt
RE: JDE-2.2.9beta8 available at
OK, I downloaded and installed beta13 and beta3, respectively, and that problem is solved. But now, when I try to set a breakpoint, the assertion in jde-bug-toggle-breakpoint that the source file must be in jde-db-source-directories fails. Looking with my meagre lisp skills at jde-db-src-dir-matches-file-p, it seems to do a string comparison of path entries. In playing with this, I have set jde-db-source-directories to: (c:/mydocu~1/javaco~1/ c:/mydocu~1/javaco~1/dbgtest/) The file is called Main.java and is in the package dbgtest, meaning that as I understand it, the normal value for jde-db-source-directories is just the first entry. The normal path name is of course C:/My Documents/Java Code, but since spaces are problematic, I usually avoid them. I guess the problem could be that the string comparison doesn't realise that they are the same directory? / Petter -Original Message- From: Berndl, Klaus [mailto:[EMAIL PROTECTED]] Sent: den 21 januari 2002 15:06 To: 'Paul Kinnucan'; Petter Måhlén; 'ECB-Mailing List' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: JDE-2.2.9beta8 available at I didn't realize that this release requires semantic-1.4beta12 and eieio-0.17beta3. This was pointed out to me by Karsten Ensinger. Thanks Karsten. I would strongly recommend using latest beta13 and not beta12 of semantic, because beta12 has really some drawbacks related to the new auto. reparsing feature. I have discussed this a long with Eric and David and the result is beta13 which is much safer with respect to this point for itself and there is also a new really helpful hook 'semantic-before-toplevel-bovination-hook. IMHO all tools needing a semantic-version = beta12 should insist in beta13! Here is what i have first mailed Eric and David about the beta12 version: ;; - currently parsing a non finished defun results in complete wrong ;; parsing in the rest of the file. Therefore the auto-parse feature is ;; quite unusable because if you code a function/method which is of course ;; not parsable during coding (in case not all closing parens, braces etc. ;; are already set correct) and you stop coding (because you have to reflect ;; some aspects) for a longer time than the idle time you define in ;; `semantic-auto-parse-idle-time' semantic parses the not finished ;; function/method, this parsing fails probably and therefore all the rest ;; of the file is either parsed completely wrong (java) or not at all ;; (elisp). It would be much better if semantic would recognice the next ;; beginning of a defun (elisp: (defun...) in column 0; C/C++/java: not so ;; simple but should be possible) and then parse from the next defun so only ;; the current coded function/method can't be parsed but the rest of the ;; file is still parsed correctly. With beta13 and the new hook you can do something like the following: ;; This prevents reparsing the buffer if not at least full-balanced concerning ;; parens, brackets and braces. (add-hook 'semantic-before-toplevel-bovination-hook (function (lambda () (condition-case data ;; Buffer can't have more than (point-max) sexps. (not (scan-sexps (point-min) (point-max))) (error nil) Eric told me that the next semantic 14 release ( beta13) is much better and saver with respect to the auto. parsing feature. But with beta13 and even the workaround above is works also very well now! Klaus
RE: JDE-2.2.9beta8 available at
Hi again, It turned out that it works if I set the jde-db-source-directories variable to: (c:/My Documents/Java Code) So I guess that the problem is in fact that several path names can map to one file, especially for Windows. / Petter -Original Message- From: Petter Måhlén [mailto:[EMAIL PROTECTED]] Sent: den 21 januari 2002 15:44 To: Berndl, Klaus; 'Paul Kinnucan'; 'ECB-Mailing List' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: JDE-2.2.9beta8 available at OK, I downloaded and installed beta13 and beta3, respectively, and that problem is solved. But now, when I try to set a breakpoint, the assertion in jde-bug-toggle-breakpoint that the source file must be in jde-db-source-directories fails. Looking with my meagre lisp skills at jde-db-src-dir-matches-file-p, it seems to do a string comparison of path entries. In playing with this, I have set jde-db-source-directories to: (c:/mydocu~1/javaco~1/ c:/mydocu~1/javaco~1/dbgtest/) The file is called Main.java and is in the package dbgtest, meaning that as I understand it, the normal value for jde-db-source-directories is just the first entry. The normal path name is of course C:/My Documents/Java Code, but since spaces are problematic, I usually avoid them. I guess the problem could be that the string comparison doesn't realise that they are the same directory? / Petter -Original Message- From: Berndl, Klaus [mailto:[EMAIL PROTECTED]] Sent: den 21 januari 2002 15:06 To: 'Paul Kinnucan'; Petter Måhlén; 'ECB-Mailing List' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: JDE-2.2.9beta8 available at I didn't realize that this release requires semantic-1.4beta12 and eieio-0.17beta3. This was pointed out to me by Karsten Ensinger. Thanks Karsten. I would strongly recommend using latest beta13 and not beta12 of semantic, because beta12 has really some drawbacks related to the new auto. reparsing feature. I have discussed this a long with Eric and David and the result is beta13 which is much safer with respect to this point for itself and there is also a new really helpful hook 'semantic-before-toplevel-bovination-hook. IMHO all tools needing a semantic-version = beta12 should insist in beta13! Here is what i have first mailed Eric and David about the beta12 version: ;; - currently parsing a non finished defun results in complete wrong ;; parsing in the rest of the file. Therefore the auto-parse feature is ;; quite unusable because if you code a function/method which is of course ;; not parsable during coding (in case not all closing parens, braces etc. ;; are already set correct) and you stop coding (because you have to reflect ;; some aspects) for a longer time than the idle time you define in ;; `semantic-auto-parse-idle-time' semantic parses the not finished ;; function/method, this parsing fails probably and therefore all the rest ;; of the file is either parsed completely wrong (java) or not at all ;; (elisp). It would be much better if semantic would recognice the next ;; beginning of a defun (elisp: (defun...) in column 0; C/C++/java: not so ;; simple but should be possible) and then parse from the next defun so only ;; the current coded function/method can't be parsed but the rest of the ;; file is still parsed correctly. With beta13 and the new hook you can do something like the following: ;; This prevents reparsing the buffer if not at least full-balanced concerning ;; parens, brackets and braces. (add-hook 'semantic-before-toplevel-bovination-hook (function (lambda () (condition-case data ;; Buffer can't have more than (point-max) sexps. (not (scan-sexps (point-min) (point-max))) (error nil) Eric told me that the next semantic 14 release ( beta13) is much better and saver with respect to the auto. parsing feature. But with beta13 and even the workaround above is works also very well now! Klaus
RE: Missing jdebug key bindings
It could be that the key bindings only work in a window with jde-mode. Are you sure that the input focus is in the window with the Java file? / Petter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Crossley Sent: den 15 januari 2002 14:47 To: [EMAIL PROTECTED] Subject: Missing jdebug key bindings I'm running JDEE 2.2.8 on Xemacs 21.4.4. Everything is working fine except my JDebug key bindings. The variable, `jde-bug-key-bindings', looks correct and the function, 'jde-bug-keys', reports what I would expect. But when debugging, I get a C-c C-z not defined error when trying to step, etc. Any advice?
RE: jde-complete methods / variable ...
I was involved ever so slightly in correcting a bug in that code, and at that time, it was recursive to check also inherited methods and variables. And as far as I can tell in Completion.java for 2.2.9beta6, it is still the case (recursiveListMethods, recursiveListFields, etc.). Are you sure it is only limited to the current class? / Petter -Original Message- From: J. T. [mailto:[EMAIL PROTECTED]] Sent: den 12 december 2001 16:06 To: [EMAIL PROTECTED] Subject: jde-complete methods / variable ... After looking at the java src code, I noticed that the completion of methods (and also for variables) are limited to those declared by the class/interface at point. My guess is this is for efficiency reason. But what about providing a customization or a different function to complete with all the methods (declared AND inherited)? Thanks, j.t. __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com
RE: Renaming Proposal
Is jmode short for Jmode is MOre than a Development Environment? Jmode Makes Other De:s Extinct? Jmode Means Ok Development Environment? -Original Message- From: Latchezar M. Dimitrov [mailto:[EMAIL PROTECTED]] Sent: den 18 juli 2001 23:29 To: Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: Re: Renaming Proposal Hi, I like jmode too. How about slight change with big consequencies?:-) That is, jdm (java development mode of course)? Thanks and sorry if it's too late. Latchezar PS. BTW, I've made a suggestion for j-d-e earlier but haven't heard any comments? Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm From: William L Anderson [EMAIL PROTECTED] Date: Wed, 18 Jul 2001 12:15:11 -0400 To: Paul Kinnucan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Renaming Proposal jmode- is a good choice; could use jm- for an abbreviation if it's not already in use in another emacs package. -WLA Latchezar (Lucho) Dimitrov home: (336) 794-2094 mailto:[EMAIL PROTECTED]http://www.wfu.edu/~dimil01g/ ... If you think education is expensive, try ignorance. -- Derek Bok, president of Harvard
RE: jde-gen-get-package-statement
Another option could be to use the jde-package-search-classpath-variables customisation variable, where you specify variables that contain paths to search for source files. I am not sure, but I think that the first variable specified there should really be jde-db-source-directories. That should be the place to look for .java files, not the class path, if you want to make it possible to separate .class and .java files. / Petter -Original Message- From: Javier Lopez [mailto:[EMAIL PROTECTED]] Sent: den 21 maj 2001 04:26 To: Molitor, Stephen; [EMAIL PROTECTED] Subject: RE: jde-gen-get-package-statement That could do it. It works by looking if your current directory is accessible from your classpath, and use that information to suggest a package. Since the directory where you have your .java files is not in the classpath(I am assuming this is the case, by what you said) is does not suggest anything. You could probably just add the root directory where you keep your .java files to the jde-global-classpath variable. Javier -Original Message- From: Molitor, Stephen [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 20, 2001 9:51 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: jde-gen-get-package-statement Well, I do have jde-global-classpath set up (and everything compiles and runs just fine now). But, I have the global classpath pointing to my .class file output directory, NOT my .java sources directory tree. Could that be the problem? Thanks. Steve Molitor [EMAIL PROTECTED] -Original Message- From: Javier Lopez [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 20, 2001 7:17 PM To: Molitor, Stephen; [EMAIL PROTECTED] Subject: RE: jde-gen-get-package-statement It already does but you have to have the jde-global-classpath variable set up. Javier -Original Message- From: Molitor, Stephen [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 20, 2001 2:15 PM To: [EMAIL PROTECTED] Subject: jde-gen-get-package-statement Is there any way to get jde-gen-get-package statement to default to the current package, based on the directory of the buffer relative to the root source directory? Thanks! Steve Molitor [EMAIL PROTECTED]
