Beanshell is unable to find ant.jar
Hi, I'm using AntServer. In the last few weeks, I frequently received the following error message when I tried to build my project: You need ant.jar in the beanshell classpath. The beanshell uses jde-global-classpath or the environment variable CLASSPATH. I could figure out, that it occurs when beanshell is started before jde-ant has been loaded. This happens when I try to build the project after compiling a single file of this project. If jde-ant-home is not bound when beanshell starts, ant.jar will not be added to beanshell's classpath. I've modified my local beanshell.el to fix the problem: (defun bsh-internal (optional display-buffer) (let ((bsh-buffer-name *bsh*)) (if (not (comint-check-proc bsh-buffer-name)) (let* ((bsh-buffer (get-buffer-create bsh-buffer-name)) ;; - ;; (ant-home (if (boundp 'jde-ant-home) ;; (if (string= jde-ant-home ) (getenv ANT_HOME) ;; jde-ant-home))) ;; MS: (project-ant-home (jde-get-project 'jde-ant-home jde-current-project)) (ant-home (if (and (boundp 'jde-ant-home) (not (string= jde-ant-home ))) ;; jde-ant loaded jde-ant-home (if (and project-ant-home (not (string= project-ant-home ))) ;; jde-ant not loaded but jde-ant-home set in project file project-ant-home ;; jde-ant-home not set in project file and not customized (getenv ANT_HOME ;; - (jde-java-directory I'm absolutly not sure whether this is the best or even a good solution. But it seems to work and I hope it helps Paul or Javier to fix the problem. I would like to mention two things related with this problem: - AntServer.java is not part of the distribution. Is it intentionally omitted? - The error message given by AntServer should mention jde-ant-home and ANT_HOME. Finally, I would like to say, that I'm already using JDE for a couple of years and I'm really happy with it. Martin
Re: AW: auto newline, indent and close brace on open brace, return
Hi Paul, Berndl, Klaus wrote: Here is a better way to determine the syntactiy context of current point, means if point stays within a line-comment, block-comment or within a string. IMHO this is more robust than jde-line-has-incomplete-string...and uses well proved Emacs-concepts for this instead of fiddling with some regexps and increasing numbers ;-) (defun syntactic-context () Check in which syntactic context point is. Return nil if no special context meaning, otherwise 'string if within a string, 'comment if within a line-comment and 'block-comment if within a block-comment. (let* ((beg (save-excursion (beginning-of-defun) (point))) (state (save-excursion (parse-partial-sexp beg (point) (cond ((nth 3 state) 'string) ((nth 4 state) (if (member major-mode '(c-mode c++-mode java-mode jde-mode)) (if (nth 7 state) 'comment 'block-comment) 'comment)) (t nil This function returns 'string if point is within a string - so also when point is at the end of an unterminated string. In that situation a newline-command should insert a (java)string terminator and so on ... As already done by the code of this thread. This has the side-effect that when point stays within a terminated string a newline-command breaks this string by adding a new terminator behind the break...so the smart newline-command does not only for unterminated strings the right thing but also for terminated. jde-parse-comment-or-quoted-p doen't work reliable. I propose to reimplement this function using parse-partial-sexp. Since I've already made changes on jde-parse.el, I could do this, if you agree. Off topic: JDEE does this also with all the template-stuff - where IMHO somehow cumbersomely is specified if a newline after a brace or not etc... all this could be done more nifty with mechanism of cc-mode and tempo, so the user specifies with cc-mode when he wants newlines before or after praces etc. and tempo uses this informations instead of introducing new options by JDEE so the user has to customize the same thing at differrent places. Since I do already work on the templates, I could move the kr stuff to a function (or macro). This would finally allow to change the way it is implemented at one single place. Regards, Martin
Re: Several errors with Beta 3
Wolfgang Pausch wrote: Hello, Hi Wolfgang, abbreviation handling has changed with JDE 2.3.4beta3. Unfortunatly, the new implementation uses a feature of define-abbrev which doesn't exist in XEmacs. XEmacs doesn't support expansions other than string or nil. The following changes should fix the problem. Sorry, I see no change - the errors are still there. However, I am not 100% sure wether the code is really called. If I for example place an (error abc) - line in jde-import-all, located in the jde-import.el in the same directory, the error shows up as expected. But, if I do the same in one of the functions affected by the code you sent below, it never shows up, even if I replace the complete code of jde-init-abbrev-table with (error abc) - the behaviour isn't changed by that. (no, I don't know of any .elc-files). How can I assure that the code is really called? Usually, jde-init-abbrev-table is called when jde-mode is activated. You can call it interactively. After that, abbreviations should work in the current buffer. HTH, Martin Thanks, Wolfgang
Re: Several errors with Beta 3
Wolfgang Pausch wrote: snip/ However, many things don't work - for example, typing if leads to ifif -expansion - even in comments, typing abbrevs like pri causes the error Symbols value as variable is void: --expansion--, I occasionally get other errors too. But, the behaviour definitely has changed after installing cedet, so it is recognised in some way. (I have added the line activating the semantic-functions later, this changed the behaviour of xemacs/JDE, but why didn't JDE complain about missing functions before???) Hi Wolfgang, abbreviation handling has changed with JDE 2.3.4beta3. Unfortunatly, the new implementation uses a feature of define-abbrev which doesn't exist in XEmacs. XEmacs doesn't support expansions other than string or nil. The following changes should fix the problem. I just replaced the third argument of define-abbrev by (if jde-xemacsp abbrev t). -- jde.el: (defun jde-init-abbrev-table () Load the abbrev table. Load it with a set of abbrevs that invoke an anonymous function that does the expansion only if point is not in a quoted string or a comment. ;; Note the use of lexical-let - must have the common lisp packages ;; around, since the anonymous function needs the closure provided by ;; lexical-let. (interactive) (mapc (lambda (x) (lexical-let ((abbrev (car x)) ; this is the abbrev, lexically scoped (expansion (cdr x))) ; this is the expansion (define-abbrev local-abbrev-table abbrev (if jde-xemacsp abbrev t) (lambda () (unless (jde-parse-comment-or-quoted-p) (delete-backward-char (length abbrev)) ; remove abbreviation and (insert expansion))) ; insert expansion 0))) jde-mode-abbreviations) (if jde-gen-cflow-enable (jde-gen-load-abbrev-templates)) (setq abbrevs-changed nil)) -- jde-gen.el: (defun jde-gen-load-abbrev-templates () Defines jde-mode abbrevs for the control flow templates. (loop for template in jde-gen-abbrev-templates do (let ((abbrev (car template))) (define-abbrev local-abbrev-table abbrev (if jde-xemacsp abbrev t) ;; Hack (see note below) 'jde-gen-abbrev-hook 0 As I don't think that JDE is that buggy, I suspect I made some mistake. No, its my mistake. I didn't test my modifications with XEmacs :-( Regards, Martin
Re: default value of jde-gen-final-arguments problem
Hi Yoon Kyung Koo, Checkstyle complains about non-final arguments in the default configuration delivered with JDEE. In order to avoid these complaints, the default is t. Regards, Martin Yoon Kyung Koo wrote: Hi, all I found that the default value of jde-gen-final-arguments is t, so it inserts final modifiers to method arguments or return types. It affects other functions such as jde-wiz-get-set-methods. I think the default value of nil is a safer choice. Regards, Yoon Kyung Koo
Re: Jde-import.el
Paul Kinnucan wrote: 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? Hi Paul, I like Petter's idea. The solution he published several weeks ago has the drawback, that it is hard-coded and can't be customized by users. But the feature itself is quite useful. What about the following improvement: jde-import-excluded-packages will be replaced by: (defcustom jde-import-excluded-classes '((^bsh\\..* . nil) (^java\\.lang\\.[^.]*$ . t) (^sun\\..* . nil) (^com\\.sun\\..* . nil) (jde-import-exclude-current-package . t)) ... :group 'jde-project :type '(repeat (cons :tag Exclude rule (choice :tag Exclude test (regexp :tag Regexp) (function :tag Exclude test function)) (boolean :tag Exclude synonyms The car of each cons has the same meaning as the elements in jde-import-excluded-packages. The cdr controls whether all synonyms of matching classes should be excluded or not. jde-import-exclude-imports uses jde-import-excluded-classes and does the whole job. As a side effect, this would ensure, that jde-import-import excludes the same classes as jde-import-all. The obvious drawback is that this change would break existing customizations. Nevertheless, I think it's worth to think about it. 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. It's already possible to exclude single classes with jde-import-excluded-packages. Only the name of the variable is a bit confusing. That's the reason why I used the name jde-import-excluded-classes in the above example ;-) Regards, Martin Paul
Re: Jde-import.el
Two additional suggestions: jde-import-import takes a fully qualified classname. If a user types a fully qualified name, he or she usually wants exactly that class to be imported. Therefore, jde-import-import should not exclude classes at all. In order to allow classes to be imported which would be excluded by jde-import-exclude-imports, it would be desirable to disable excluding temporarily. This could be done by a prefix argument. Such a feature would be useful for jde-import-all and for jde-import-find-and-import. Once implemented, one could import xyz.String by typing C-u C-c C-v C-z String RET even if synonyms of java.lang classes would be excluded by jde-import-exclude-imports. Thoughts? Regards, Martin Martin Schwamberger wrote: Paul Kinnucan wrote: 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? Hi Paul, I like Petter's idea. The solution he published several weeks ago has the drawback, that it is hard-coded and can't be customized by users. But the feature itself is quite useful. What about the following improvement: jde-import-excluded-packages will be replaced by: (defcustom jde-import-excluded-classes '((^bsh\\..* . nil) (^java\\.lang\\.[^.]*$ . t) (^sun\\..* . nil) (^com\\.sun\\..* . nil) (jde-import-exclude-current-package . t)) ... :group 'jde-project :type '(repeat (cons :tag Exclude rule (choice :tag Exclude test (regexp :tag Regexp) (function :tag Exclude test function)) (boolean :tag Exclude synonyms The car of each cons has the same meaning as the elements in jde-import-excluded-packages. The cdr controls whether all synonyms of matching classes should be excluded or not. jde-import-exclude-imports uses jde-import-excluded-classes and does the whole job. As a side effect, this would ensure, that jde-import-import excludes the same classes as jde-import-all. The obvious drawback is that this change would break existing customizations. Nevertheless, I think it's worth to think about it. 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. It's already possible to exclude single classes with jde-import-excluded-packages. Only the name of the variable is a bit confusing. That's the reason why I used the name jde-import-excluded-classes in the above example ;-) Regards, Martin Paul
Re: Refreshing bsh database
Hi Eric, you don't need to restart beanshell. It is sufficient to call jde-wiz-update-class-list. You can use C-c C-v C-q to call it. This works quite well. But I think it would be even more convenient to have a compile-finish-hook which calls jde-wiz-update-class-list. There is also menu entry which calls this function: JDE-Code Generation-Wizards-Update Class List Since jde-wiz-update-class-list is necessary for jde-import, submenu JDE-Interpreter (or even a new submenu) might be a better place for Update Class List. Regards, Martin Erik Curiel wrote: I also notice that the jde-import suffers the same problem, that it won't be able to find newly created classes unless bsh is restarted. Thanks!!! Erik Curiel On Thu, 5 Aug 2004, Paul Kinnucan wrote: Robert Mecklenburg writes: It often occurs that jde-complete says no completion at point when it should not. In these cases, exiting and restarting the bean shell cures the problem. One of the most common cases is when a new class has been defined (after the bean shell has started). It seems to me that a refresh-classes command for the bean shell would be useful here. Does one exist? Hi Robert, Completion for a new class will work only if the new class has been compiled. That is because JDEE's implementation of completion uses Java reflection to determine the names of a class's members. The JDEE provides a jde-compile-finish-hook function, jde-compile-finish-flush-completion-class, that is supposed to update the JDEE's completion subsystem after compilation of the class. What this function does is flush the JDEE's completion cache. The JDEE's completion cache is an Emacs Lisp variable that lists the members of all classes that have be completed since the beginning of the session or the cache has been flushed. Flushing the cache forces the JDEE to regenerate the completion info for the class that has just been recompiled. This may not work for new classes. The reason is that the Java side of the JDEE's completion subsystem maintains its own cache of all classes on the current project's classpath. This cache is updated whenever you switch projects. However, it's possible the cache is not being updated everytime you compile a class. Hence, the completion subsystem would never see a new class. I will investigate further this evening and if this is the case provide a fix in the next beta release. Paul
Re: [jde] [ANNOUNCEMENT] JDEE 2.3.4beta6 available at ...
Paul Kinnucan wrote: Raul Acevedo writes: On Wed, 2004-10-13 at 01:14 -0400, Paul Kinnucan wrote: * Update the class list used by completion and by code generation wizards after compiling a class or building a project. This should ensure that completion and the wizards work for new classes and changes to existing classes after compiling new or changed classes. This is extremely slow on large projects, even if I'm just compiling a single class. I'm assuming that's because it's updating everything in the class path. If so, can it be changed to only update the class that was just compiled? And until that happens, how can I disable it and run it manually when necessary? It takes about 30 seconds right now. Hi Raul, I'll see if I can get the first approach to work. Meanwhile, you can easily disable this feature by removing je-compile-finish-update-class-info from jde-compile-finish-hook. Hi Paul, I've sent you an extension to the java part of JDEE in November 2003. It may help solve this problem. AFAIR, you didn't include this change in JDEE. I introduced the method JdeUtitities.updateClassList(String path), which updates only the given path. The idea was to call the method after compiling with jde-compile-option-directory as argument. There were a couple of other java related changes in this mail. I don't remember all the details. The code may well be out of date, but anyway, if you want, I can re-send the mail or only the relevant part of it. Martin Paul
Re: Problem loading JDE in Emacs CVS
Nascif Abousalh-Neto wrote: Hi Martin, Thanks for the feedback, I am still battling it. Do you have the latest cc-mode in your system, or are you using the one that comes with Emacs? I'm using cc-mode coming with Emacs. I've Cygwin installed and use the makefiles to build the CEDET and JDEE. Martin Regards, Nascif -Original Message- From: Martin Schwamberger [mailto:[EMAIL PROTECTED] Sent: Friday, January 07, 2005 7:59 AM To: Nascif Abousalh-Neto Cc: jde@sunsite.dk Subject: Re: Problem loading JDE in Emacs CVS Hi Nascif, I'm using this emacs build together with JDEE 2.3.5. I don't experience this kind of problem. java-font-lock-keywords-3 is defined. Did you recompile CEDET (and the other packages, JDEE depends on)? Martin Nascif Abousalh-Neto wrote: Hi, I am trying out the Emacs build from CVS for Windows (http://www.crasseux.com/emacs/, posted by Martin Schwamberger, thanks!) and I am having some problems. When I try to load JDE, I get the following error: Debugger entered--Lisp error: (void-variable java-font-lock-keywords-3) jde-java-font-lock-keywords(nil) jde-java-font-lock-setup-keywords() require(jde-java-font-lock) eval-buffer(#buffer *load*2 nil jde nil t) ;;; Reading at buffer position 2829 load-with-code-conversion(c:/home/emacs/jde-2.3.5/lisp/jde.el jde nil t) require(jde) eval-buffer(#buffer *load* nil ~/.emacs nil t) ;;; Reading at buffer position 15813 load-with-code-conversion(c:/home/.emacs ~/.emacs t t) load(~/.emacs t t) Any ideas? I already removed all the .elc and byte-compiled again. Regards, Nascif
Re: Buffer is read-only: #buffer *compilation*
Javier S. Lopez wrote: Paul Kinnucan [EMAIL PROTECTED] writes: There are probably a few ways to work around the problem 1. Set the inhibit-read-only flag 2. Make our compiles a minor mode or rewrite the way we use it. There is a new method compile-setup that takes a flag that allows you to control this behavior. Hi Javier, I've changed jde-compile.el according to your first idea. See diff below. I will point you to the email thread where Richard Stallman talks about it. I don't agree with him, I think Stefan Monnier is right on this one. http://lists.gnu.org/archive/html/emacs-devel/2004-11/msg8.html IMHO, RMS is right here. Programs can easily change read-only compilation buffers and users shouldn't. Martin Javier Javier S. Lopez writes: Anderson, Timothy K [EMAIL PROTECTED] writes: Hi, Using GNU Emacs CVS, JDE 2.3.4, CEDET 1.0beta3b. When trying to compile code with C-C C-V C-C, I am getting the following error: save-excursion: Buffer is read-only: #buffer *compilation* This looks familiar... I had the problem when running the latest emacs from cvs. All the compilation buffers are read only, I don't know what a good fix for this is. I just changed the compile.el file to avoid making the buffers readonly. But we probably need a better fix for this. How can the compilation buffers be read-only and allows error and other messages to be written into them? This sounds like a bug in the CVS version of Emacs. Paul Javier This happens every time - I think I have tried almost every combination of customize variables (at least, it feels that way). Has anyone else seen this? What should I do to find the cause? Thanks for any help. Tim Anderson CONFIDENTIALITY This e-mail and any attachments are confidential and also may be privileged. If you are not the named recipient, or have otherwise received this communication in error, please delete it from your inbox, notify the sender immediately, and do not disclose its contents to any other person, use them for any purpose, or store or copy them in any medium. Thank you for your cooperation. -- Javier S. Lopez Software Developer Forum Systems, Inc. 95 Sawyer Road, Suite 110, Waltham, MA 02453 http://www.forumsys.com The information contained in this electronic mail and any attached document is the confidential and proprietary business information of Forum Systems, Inc. It is intended solely for the addressed recipient listed above. It may not be distributed in any manner without the express written consent of Forum Systems, Inc. diff -u jde-compile.el.old jde-compile.el --- jde-compile.el.old 2004-12-17 05:29:36.0 +0100 +++ jde-compile.el 2005-01-25 13:14:47.585153200 +0100 @@ -714,24 +714,23 @@ (save-excursion (set-buffer outbuf) - - (insert (format cd %s\n default-directory)) - - (insert (concat - compiler-path - - (mapconcat (lambda (x) -(if (and flag - jde-compile-option-hide-classpath) -(progn - (setq flag nil) - ...) - (if (not (string= x -classpath)) - x -(progn - (setq flag t) - x args ) - \n\n)) + (let ((inhibit-read-only t)) ; make compilation buffer temporarily writable +(insert (format cd %s\n default-directory)) +(insert (concat + compiler-path + + (mapconcat (lambda (x) + (if (and flag + jde-compile-option-hide-classpath) + (progn +(setq flag nil) +...) +(if (not (string= x -classpath)) +x + (progn +(setq flag t) +x args ) + \n\n))) (let* ((process-environment (cons EMACS=t process-environment)) (w32-quote-process-args ?\) @@ -770,33 +769,27 @@ , (setq arg-array (concat arg-array })) - - + (save-excursion (set-buffer (oref (oref this buffer) buffer)) - - (insert CompileServer output:\n) - (insert \n) - - (let (flag temp) - (setq temp - (mapconcat - (lambda (x) - (if (and flag - jde-compile-option-hide-classpath) - (progn - (setq flag nil) - ...) - (if (not (string= x -classpath)) - x -
Re: changing cc-mode settings in jde-mode-hook
I just noticed that I've forgotten to put the list on CC ... [EMAIL PROTECTED] wrote: Martin Schwamberger writes: (add-hook 'jde-mode-hook (function (lambda () (c-set-offset 'defun-block-intro 0 Martin, That did it, thanks very much! Regards, Patrick S P Engineering, Inc.| The experts in large scale distributed OO | systems design and implementation. [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML)
