Re: Turning off the style check for tabs
Try M-x jde-checkstyle-customize -- Ed Charles Curley wrote: My client likes tabs in files. How do I turn off the style check for tabs in JDEE? I've already found out that you can, but I don't see anything in the checkstyle or jdee docs that say how you do this. Thanks.
Re: Turning off the style check for tabs
I don't know. This may be relevant: ^H v indent-tabs-mode -- Ed Charles Curley wrote: On Thu, Jun 09, 2005 at 12:54:15PM -0400, Ed Mooney wrote: Try M-x jde-checkstyle-customize Right, been there. The closest thing I could find was Jde Checkstyle Style, but how do you use it? How do you define a style? Where is the Sun style defined? [ ... ]
Re: cygwin emacs path problem
I see. There's a version[1] of emacs you can select and install by running http://cygwin.com/setup.exe;. I propose we reserve the name Cygwin emacs for that one :-). In the meantime, I've reverted to using Windows/NT/XP emacs[2], because jde-open-class-at-point (C-c C-v C-y) doesn't work (for me) from Cygwin emacs. That brings us (me, anyway) full-circle to Leo's original posting[3], but remains consistent with the JDE User's Guide[4]. -- Ed [1] E.g.: http://mirrors.rcn.net/pub/sourceware/cygwin/release/emacs/ [2] http://ftp.gnu.org/gnu/windows/emacs/ [3] http://www.mail-archive.com/jde@sunsite.dk/msg08252.html [4] http://jdee.sunsite.dk/jdedoc/html/jde-ug/jde-ug-content.html#Intro Henry S. Thompson wrote: Ed Mooney [EMAIL PROTECTED] writes: FWIW, I started using JDEE with Cygwin emacs again after Henry Thompson reported doing so successfully a while back[1]. The only functionality I've missed so far is with jde-find[2]. This compares much favorably with a year ago or so, when (as I recall) C-c C-v C-c didn't work. More clarification :-) -- I use Cygwin XEmacs (www.xemacs.org), not Cygwin Emacs (www.gnu.org). In the past I've used the cygwin installer provided by the XEmacs people [1], which gives you a choice at install time of using Cygwin X or native Windows, but that has stuck at 21.4.13 for some time, so more recently I've compiled the sources myself under cygwin using gcc, using the native windows settings. As I've said before on this thread, I'm not clear why Ed and others are having trouble with file paths, as (admittedly after some trial and error) I believe I have it all working fine. I'm attaching my complete jde-related initialisation information, in the hopes this may help others. ht [1] http://www.xemacs.org/Download/win32/setup.exe [ ... ]
Re: cygwin emacs path problem
With (jde-cygwin-path-converter (quote (jde-cygwin-path-converter-internal))): Starting the BeanShell. Please wait... Beanshell expression evaluation error. Expression: jde.util.JdeUtilities.setProjectValues(/cygdrive/c/JAXB2.0/jaxb-sqe/prj.el, c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\activation.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\istackp.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\jaxb-api.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\jaxb-impl.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\jaxb-xjc.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\jaxb1-impl.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\jsr173_1.0_api.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\relaxngDatatype.jar;c:\JAXB2.0\jaxb-sqe\..\jaxb2.0\lib\xsdlib.jar;c:\JAXB2.0\jaxb-sqe\classes;c:\JAXB2.0\jaxb-sqe\util\lib\dom4j-1.5.2.jar;c:\JAXB2.0\jaxb-sqe\tmp;/files/jeeves.jeeves/test-commons/reporter/build/classes); Error: // Error: Error parsing input: bsh.TokenMgrError: Lexical error at line 1, column 84. Encountered: J (74), after : \c:\\ // Error: Parser Error: Parse error at line 1, column 11. Encountered: . bsh-eval-r error: Beanshell result is null. Cannot evaluate. Expression: jde.util.JdeUtilities.classExists(Driver); bsh-eval-r error: Beanshell result is null. Cannot evaluate. Expression: jde.util.Completion.getClassInfo(Driver,0); bsh-eval-r error: Beanshell result is null. Cannot evaluate. Expression: jde.util.Completion.getClassInfo(Driver,1); Beanshell expression evaluation error. Expression: jde.util.Completion.getClassInfo(Driver,2); Error: // Error: EvalError: Class or variable not found: pi.jar : at Line: 1 : in file: unknown file : pi .jar [2 times] bsh: Beanshell eval error. See messages buffer for details. Mark set [2 times] With (jde-cygwin-path-converter (quote (jde-cygwin-path-converter-cygpath))): Starting the BeanShell. Please wait... Can not find the source for features.Features. -- Ed Henry S. Thompson wrote: Ed Mooney [EMAIL PROTECTED] writes: In the meantime, I've reverted to using Windows/NT/XP emacs[2], because jde-open-class-at-point (C-c C-v C-y) doesn't work (for me) from Cygwin emacs. That brings us (me, anyway) full-circle to Leo's original posting[3], but remains consistent with the JDE User's Guide[4]. It would be _very_ nice to sort this out -- jde-open-class-at-point works fine for me in Cygwin XEmacs (native). One more time -- how does jde-open-class-at-point fail for you? ht
Re: cygwin emacs path problem
Now I'm confused. Is the version of emacs[1] you can install by running http://cygwin.com/setup.exe A or B? I had thought it was A. If not, where can I get A? -- Ed [1] E.g.: http://mirrors.rcn.net/pub/sourceware/cygwin/release/emacs/ Jason Rumney wrote: Paul Kinnucan wrote: Hi Felix, As I understand it, there are two versions of cygwin emacs: (A) a version of Unix Emacs modified specifically to run in the Cygwin environment and (B) the standard Unix version of Emacs compiled, using cygwin gcc, to run in the Cygwin environment JDEE supports the A version. It does not support the B version. The reason for this is that years ago, long before the B-version existed, some JDEE users asked for A version support and some of those users actually contributed code necessary to support the A version. Meanwhile, until now, there has been no demand for B-version support. Really this is a cygwin problem. A cygwin version of Emacs needs to be modified to fit its environment, as the 'A' version was. I'm not sure what happened to those patches, but it is unreasonable of the Cygwin maintainers to expect the maintainers of every other package to make changes to accomodate Cygwin's lack of fitting in with its environment so that they themselves can use unmodified code targetted at GNU/Linux.
Re: cygwin emacs path problem
Hi Paul, Ah, okay. FWIW, I started using JDEE with Cygwin emacs again after Henry Thompson reported doing so successfully a while back[1]. The only functionality I've missed so far is with jde-find[2]. This compares much favorably with a year ago or so, when (as I recall) C-c C-v C-c didn't work. Thanks for all your great work, -- Ed [1] http://www.mail-archive.com/jde@sunsite.dk/msg08253.html [2] http://www.mail-archive.com/jde@sunsite.dk/msg08287.html Paul Kinnucan wrote: Hi Ed, I think the version of Emacs that I've been calling the A version is actually the cygwin version of XEmacs. Thus, the support in the JDEE for cygwin versions of Emacs is actually geared to the cygwin version of XEmacs. This would explain the difficulty that people are having with trying to use the JDEE with the cygwin version of Emacs. It's been a long time since I've dealt with this issue and my memory is obviously fuzzy. Anyway, the bottom line is the same. The current JDEE cygwin support was not designed for the current cygwin version of Emacs and hence it would not be surprising if it does not fully support it. Paul [ ... ]
Re: cygwin emacs path problem
Try setting jde-cygwin-path-converter to jde-cygwin-path-converter-cygpath: M-x customize-variable RET jde-cygwin-path-converter FSF emacs, XEmacs and NT/Emacs are the only versions the user's guide[1] claims the JDEE supports. -- Ed [1] http://jdee.sunsite.dk/jdedoc/html/jde-ug/jde-ug-content.html#Intro Felix Dorner wrote: Hi, motivated by the ongoing cygwin thread I installed: cygwin, cygwin emacs, jde. The jde-bsh-run command now involves: cd /home/Felix/ /cygdrive/c/java/jdk1.5.0_02/bin/java -classpath /home/Felix/emacs/jde-2.3.5/ja\ va/lib/bsh.jar;/home/Felix/emacs/jde-2.3.5/java/bsh-commands;/home/Felix/emacs/\ jde-2.3.5/java/lib/checkstyle-all.jar;/home/Felix/emacs/jde-2.3.5/java/lib/jaka\ rta-regexp.jar;/home/Felix/emacs/jde-2.3.5/java/lib/jde.jar;c:\java\jdk1.5.0_02\ \lib\tools.jar bsh.Interpreter java.lang.NoClassDefFoundError: bsh/Interpreter with bsh unable tu run, the jde compile server also fails, making the whole thing almost useless. The java executable obviously cannot deal with those unix style pathnames. I did not find a real guide on setting up the jde with cygwin emacs, so I hope someone can help me here. Thanks a lot, Felix
Re: JDE does not jump to line responsible for error.
Couldn't tell if this applies to you but, in my environment, anyway, if there are more than one compilation errors for a given source line, point has to be in the first error for that line. -- Ed Christopher Balz wrote: I am using JDE 2.3.5, GNU Emacs 21.3.1 (i386-msvc-nt5.1.2600) of 2003-03-27 on buffy, on Windows XP SP2, all-up-to-date. The JDE does not take me to the line responsible for a given compilation error when I click on that line. Bummer! Thanks in advance for any help (details below). [ ... ]
retaining *JDEE Compile Server* buffer?
What's the method for retaining the *JDEE Compile Server* after compilation? It seems to be insensitive to the setting of jde-compile-enable-kill-buffer. Thanks, -- Ed
parsing casts depends on space
With point in driverMain: (Integer)driverMain.invoke ... C-c C-v C-y returns Wrong type argument: number-or-marker-p, nil Backtrace attached. C-c C-v C-y works correctly with a space after the cast: (Integer) driverMain.invoke ... It would be more convenient if jde-parse.el could handle both styles. -- Ed Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) +(3 nil) (setq chop-pos (+ 3 (string-match : to-complete))) (progn (setq to-complete (car ...)) (setq chop-pos (+ 3 ...)) (let* (... ...) uqname)) (if jde-complete-current-list (progn (setq to-complete ...) (setq chop-pos ...) (let* ... uqname))) (if qualified-name qualified-name (if jde-complete-current-list (progn ... ... ...))) (let* ((result ...) (temp ...) to-complete) (if temp (jde-parse-find-completion-for-pair temp) (jde-parse-find-completion-for-pair ... nil jde-complete-private)) (if (not jde-complete-current-list) (jde-parse-find-completion-for-pair ...)) (setq qualified-name (jde-parse-get-qualified-name result t)) (if qualified-name qualified-name (if jde-complete-current-list ...))) (cond ((eq last-char 41) (let* ... ... ... ... ...)) ((eq last-char 93) (let ... ...)) ((setq temp ...) (jde-parse-find-completion-for-pair temp t) (if jde-complete-current-list ... nil)) (t (let ... ... ... ... ...))) (let (to-complete (last-char ...)) (cond (... ...) (... ...) (... ... ...) (t ...))) (cond ((integerp expr) int) ((if ... long)) ((floatp expr) double) ((if ... float)) ((string-match false\\|true expr) boolean) ((string= ' ...) char) ((and class-at-point ...) (jde-parse-get-qualified-name class-at-point t)) ((and super-at-point ...) (jde-parse-get-qualified-name super-at-point t)) ((setq qualified-name ...) qualified-name) ((and expr class-at-point ... ...) qualified-name) (t (let ... ...))) (setq answer (cond (... int) (...) (... double) (...) (... boolean) (... char) (... ...) (... ...) (... qualified-name) (... qualified-name) (t ...))) (let ((class-at-point ...) (super-at-point ...) qualified-name chop-pos temp answer) (setq answer (cond ... ... ... ... ... ... ... ... ... ... ...)) answer) (if expr (let (... ... qualified-name chop-pos temp answer) (setq answer ...) answer)) jde-parse-eval-type-of((Integer)) jde-open-get-class-to-open(((Integer) driverMain) #(driverMain 0 10 (fontified t))) jde-open-class-at-point() * call-interactively(jde-open-class-at-point)
finding symbol in same file
I have this class:
public class hello {
public static void main(String [] args) {
hello();
}
public static void hello() {
System.out.println(Hello.);
}
}
When point's in hello() (in main()) and I type C-c C-v C-y, the JDEE
returns 'Cannot determine the class of hello.' Both the
global-classpath and sourcepath are set to .. Is this the expected
behavior?
-- Ed
Re: cannot read files in zip file after installing jde 2.3.5
I had the same problem. The symptom is that after you open an archive, you can't extract a member to its own buffer. Under 2.3.4, archive-zip-extract gets set to (unzip -qq -c). Undert 2.3.5, it gets set to (pkunzip -e -o-). (In my environment, anyway. I don't know which extraction utility is the default, but I don't seem to have customized it.) A related difference between the two JDE versions is that jde-util.el uses archive-zip-extract in 2.3.5, but not in 2.3.4. I don't understand elisp well enough to know if it's being called or defined. I fixed things by: M-x customize-apropos RET archive-zip-extract Enter unzip for Program: and -qq and -c as options. Then, Save for Future Sessions. -- Ed Paul Kinnucan wrote: Yoon Kyung Koo writes: After installing jde 2.3.5 I cannot read files embedded in zip or jar file. The error message is as follows : Searching for program: no such file or directory, pkunzip I use unzip instead of pkunzip. ;; use unzip instead of pkunzip (setq archive-zip-use-pkzip nil) The JDEE does not set this variable, as far as I know. Paul -- Ed Mooney |Sun Microsystems, Inc.|Time flies like Java Web Services |UBUR02-201|an arrow, but [EMAIL PROTECTED] |1 Network Drive |fruit flies like 781-442-0459 |Burlington, MA 01803 |a banana. Groucho
Re: Debugging remote 1.4.2 jvm
I couldn't get attach mode to work, either[1]. -- Ed [1] http://article.gmane.org/gmane.emacs.jdee/4017 Karr, David wrote: -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 8:05 AM To: Karr, David Cc: Paul Kinnucan; [EMAIL PROTECTED] Subject: RE: Debugging remote 1.4.2 jvm Karr, David writes: I assume attach mode is further down the road, for either jdb or Jdebug mode? I don't know why I bother writing documentation for the JDEE. I read the documentation. I couldn't get Attach mode to work. Since you replied saying you were using listen mode, I assumed you meant that Attach mode isn't working yet. If that's not the case, then I'll continue trying to get Attach working with jdb mode. Paul [ ... ]
JDEbug/Attach Process
I run test like this:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000 test
From JDEbug/Processes/Attach Process/On Local Host, I see this:
*** Debugger Output for Process 8000(1) ***
Attached to process on port 8000 of local host.
Attached VM (socket) Java Debug Interface (Reference
Implementation) version 1.4
Java Debug Wire Protocol (Reference Implementation) version 1.4
JVM Debug Interface version 1.3
JVM version 1.4.2_04 (Java HotSpot(TM) Client VM, mixed mode)
vm started...
All threads suspended...
Setting breakpoint at line 6 in c:/cygwin/usr/local/bin/java/test.java.
Setting breakpoint at line 6 in c:\cygwin\usr\local\bin\java\test.java.
However, the background of line 6 remains green and the Local
Variables buffer is empty.
Any idea what I'm doing wrong? Everything works fine if I launch test
from JDEE (C-c C-v C-d).
-- Ed
public class test {
public static void main(String[] args) {
String foo = Hello world.;
System.out.println(foo);
}
}
(jde-project-file-version 1.0)
(jde-set-variables
'(jde-db-option-connect-shared-memory-name JDEbug)
'(jde-run-option-classpath (quote (.)))
'(jde-db-option-connect-socket (quote (nil 8000)))
'(jde-debugger (quote (JDEbug)))
'(jde-db-option-classpath (quote (.)))
'(jde-sourcepath (quote (.)))
'(jde-bug-server-socket (quote (nil . 8000)))
'(jde-run-application-class test)
'(jde-bug-jre-home c:/j2sdk1.4.2_04))
Re: JDEBug: Launch process with vm args and application args?
Try setting Jde Db Option Application Args Jde Db Option Vm Args in the Jde Db Options group (JDE/Project/Options/Debug). -- Ed Matthew Weaver wrote: In JDEBug, it seems that Launch Process does not apply jde-run-option-vm-args and jde-run-option-application-args. Is there any way to launch a process with specific arguments to the application and to the vm? I know that I can start the application separately with args, and then connect to it. But this feels slow. Is it my only option (on Linux)? Thanks. -Matthew
Re: Allowing shell wildcards in jde-global-classpath and jde-sourcepath
Suraj' changes would be a great benefit for me. -- Ed Paul Kinnucan wrote: Suraj Acharya writes: I made the following changes to allow me to use wildcards in the classpath and sourcepath variables. The file expansion included with jde which expands specially named directories (for example lib) didn't do the job for me because: Thanks, Suraj. I will consider your contribution for inclusion in the next release. Paul [ ... ]
Re: Can't exec program: /:/bin/jdb
I'm forgetting which settings are necessary/sufficient, but this could be because either $JAVA_HOME/bin isn't in your PATH, you haven't registered a JDK with the JDE, or both. -- Ed Jay Rogers wrote: I get the following error when invoking jde-debug cd /home/jnr/src/java/ /:/bin/jdb -launch Factorial Can't exec program: /:/bin/jdb Comint exited abnormally with code 1 Any ideas? This is v2.3.3 on Solaris w/ emacs 21.1.
Re: makefile
Hi Paul, I recommend: if echo $(EMACS) | grep -w xemacs ; \ This works for me with Cygwin (Cygnus?) make on Windows XP. -- Ed Paul Kinnucan wrote: Ed Mooney writes: jde-2.3.4beta5/lisp/makefile fails for me like this under /usr/ccs/bin/make on Solaris 9: [EMAIL PROTECTED] make test -d ../../cedet-1.0beta2b -a -d ../../elib rm -f *.elc jde-compile-script-init echo (add-to-list 'load-path \.\) jde-compile-script-init echo (add-to-list 'load-path \../../elib\) jde-compile-script-init echo (setq debug-on-error t) jde-compile-script-init echo (load-file \../../cedet-1.0beta2b/common/cedet.el\) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init if test `echo emacs | grep -w xemacs` ; \ then emacs -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else emacs -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ fi; *** Error code 1 make: Fatal error: Command failed for target `all' Anyone else seen this? It succeeds for me with Cygwin /bin/make. It works if I change if test `echo $(EMACS) | grep -w xemacs` ; \ to if test \`echo $(EMACS) | grep -w xemacs\` ; \ or simply to if echo $(EMACS) | grep -w xemacs ; \ Does this work with Cygnus make? If so, perhaps I should change the makefile. Anybody out there a make expert who'd care to venture an opinion on the best way to resolve this issue? Paul
makefile
jde-2.3.4beta5/lisp/makefile fails for me like this under /usr/ccs/bin/make on Solaris 9: [EMAIL PROTECTED] make test -d ../../cedet-1.0beta2b -a -d ../../elib rm -f *.elc jde-compile-script-init echo (add-to-list 'load-path \.\) jde-compile-script-init echo (add-to-list 'load-path \../../elib\) jde-compile-script-init echo (setq debug-on-error t) jde-compile-script-init echo (load-file \../../cedet-1.0beta2b/common/cedet.el\) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init if test `echo emacs | grep -w xemacs` ; \ then emacs -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else emacs -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ fi; *** Error code 1 make: Fatal error: Command failed for target `all' Anyone else seen this? It succeeds for me with Cygwin /bin/make. It works if I change if test `echo $(EMACS) | grep -w xemacs` ; \ to if test \`echo $(EMACS) | grep -w xemacs\` ; \ or simply to if echo $(EMACS) | grep -w xemacs ; \ -- Ed
Re: second error on a line
Thanks, Paul. -- Ed Paul Kinnucan wrote: Ed Mooney writes: Thanks, Paul. Just to confirm, I'm talking about the case where a single line of Java code has more than one error, which show up as more than one line in the compilation buffer. E.g.: Hi Ed, I've confirmed the problem. I'll try to provide a fix. Paul [ ... ]
Re: strange problem
Hi Guy, Sounds like you might have broken the loading of cedet-1.0beta2b/semantic in the course of upgrading. Try adapting Paul's instructions at http://www.mail-archive.com/jde%40sunsite.dk/msg07525.html to your environment. -- Ed Guy Durrieu wrote: Hello, I just installed JDE on my Sun workstation, with all needed tools: jde-2.3.3 cedet-1.0beta2b elib-1.0 and I have a strange display problem. When a load a Java program for the first time all works fine (display and menus). If I kill the buffer and load the same program or another program, the display doesn't work anymore. I get the message Buffer .java was not set up for parsing and the java program appears but is not highlighted as previously. However, the JDE menu still works correctly. Did I forget something ? Did anyone get the same problem ? I work with Emacs 21.2.1, but the problem occurs with earlier versions too. Thanks in advance for your help ! Regards. --Guy Durrieu.
Re: feedback on 2.3.4beta4
Hi Paul, Paul Kinnucan wrote: Ed Mooney writes: I installed 2.3.4beta4 on Solaris 9 and have these comments. * I had to make this change to get lisp/makefile to work: all: test -d $(SEMANTIC) -a -d $(SPEEDBAR) -a -d $(ELIB) -a -d $(EIEIO) *** *** 25,31 echo (setq debug-on-error t) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init ! if test `echo $(EMACS) | grep -w xemacs` ; \ then $(EMACS) -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else $(EMACS) -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ --- 25,31 echo (setq debug-on-error t) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init ! if echo $(EMACS) | grep -w xemacs ; \ then $(EMACS) -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else $(EMACS) -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ I don't understand why you eliminated the test operator or how the script can work without it. In any case, the script won't work with cedet, which the JDEE now requires. I have submitted a version that does work to the JDEE CVS repository. Thanks. * I had to make these changes to jde.el: *** jde.el 2004/06/01 18:17:56 1.1 --- jde.el 2004/06/01 19:57:42 *** *** 38,43 --- 38,46 ;;;###autoload + (defconst cedet-version 1.0beta2b + Cedet version number.) + (defconst jde-version 2.3.4beta4 JDE version number.) Without this change, emacs complained that cedet-version is an undefined variable (or some such). This was true even though I had set jde-check-version-flag to nil. cedet-version is defined by cedet.el in the cedet package. The recommended way for loading the cedet package is adding the following line to your .emacs file. (load-file (expand-file-name ~/emacs/site-lisp/cedet/common/cedet.el)) This should eliminate the undefined variable problem. Yes, it does. However, I had been able to rely on EMACSLOADPATH up until now, which is my preferred way of finding emacs components. *** *** 1252,1257 --- 1255,1262 (defvar jde-cygwin-root-cache nil Cache of converted cygwin root directory paths.) + (defun jde-cygwin-path-converter-noop (path) path) + (defun jde-cygwin-path-converter-cygpath (path) (interactive sPath: ) (if (string-match ^[a-zA-Z]: path) This change lets me set jde-cygwin-path-converter to jde-cygwin-path-converter-noop, disabling conversion of paths beginning with /cygdrive to DOS format. Comments in jde.el led me to think that setting jde-cygwin-path-converter to jde-cygwin-path-converter-cygpath would disable such conversions on my Solaris system, but that seemed not to be the case. This should not be a problem on Solaris unless you have directories that begin with cygdrive, which seems unlikely. In any case, I think the correct way to handle this is for the JDEE to do cygwin path conversion only if the system-type is cygwin32, which is the designation for the version of XEmacs designed to run with Cygwin.. Hmmm ... sounds sensible. It certainly would be good not to do path conversion on Solaris. For example, I install emacs into /cygdrive/c on my Solaris box. That lets me maintain identical .emacs' on cygwin and Solaris (provided I'm able to rely on EMACSLOADPATH :-( ). Anyway, I've put (defun jde-cygwin-path-converter-noop (path) path) in my my-jde-mode-hook, so I don't have to tweek JDE code at all. Paul [ ... ] Thanks for all your great work, Paul. -- Ed
feedback on 2.3.4beta4
I installed 2.3.4beta4 on Solaris 9 and have these comments. * I had to make this change to get lisp/makefile to work: all: test -d $(SEMANTIC) -a -d $(SPEEDBAR) -a -d $(ELIB) -a -d $(EIEIO) *** *** 25,31 echo (setq debug-on-error t) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init ! if test `echo $(EMACS) | grep -w xemacs` ; \ then $(EMACS) -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else $(EMACS) -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ --- 25,31 echo (setq debug-on-error t) jde-compile-script-init echo (require 'jde-compat) jde-compile-script-init echo (require 'jde) jde-compile-script-init ! if echo $(EMACS) | grep -w xemacs ; \ then $(EMACS) -batch -l jde-compile-script-init -f batch-byte-compile `echo *.el` ; \ else $(EMACS) -batch -l jde-compile-script-init \ -f batch-byte-compile `ls -1 *.el | egrep -v 'jde-xemacs.el'`; \ * I had to make these changes to jde.el: *** jde.el2004/06/01 18:17:56 1.1 --- jde.el2004/06/01 19:57:42 *** *** 38,43 --- 38,46 ;;;###autoload + (defconst cedet-version 1.0beta2b + Cedet version number.) + (defconst jde-version 2.3.4beta4 JDE version number.) Without this change, emacs complained that cedet-version is an undefined variable (or some such). This was true even though I had set jde-check-version-flag to nil. *** *** 1252,1257 --- 1255,1262 (defvar jde-cygwin-root-cache nil Cache of converted cygwin root directory paths.) + (defun jde-cygwin-path-converter-noop (path) path) + (defun jde-cygwin-path-converter-cygpath (path) (interactive sPath: ) (if (string-match ^[a-zA-Z]: path) This change lets me set jde-cygwin-path-converter to jde-cygwin-path-converter-noop, disabling conversion of paths beginning with /cygdrive to DOS format. Comments in jde.el led me to think that setting jde-cygwin-path-converter to jde-cygwin-path-converter-cygpath would disable such conversions on my Solaris system, but that seemed not to be the case. With these changes, I'm up and running and intend to shake it out some more. I'm delighted no longer to see: Wrong type argument: stringp, nil when I load a second Java file (I'm running with cedet-1.0beta2b). Regards, -- Ed Mooney |Sun Microsystems, Inc.|Time flies like Java Web Services |UBUR02-201|an arrow, but [EMAIL PROTECTED] |1 Network Drive |fruit flies like 781-442-0459 |Burlington, MA 01803 |a banana. Groucho
