Re: Why the JDEE?
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul It also allows users who are, like myself, working in a Paul multilanguage environment (e.g., C/C++/Java) to use a single Paul environment for all their work. This is my primary motivation for using emacs, and JDE for java. I use many different languages. And often ones for which big flashy IDE's are not available. Besides why would I want to learn three different ways of accessing version control for instance? With Emacs it's always there, and its always the same. Paul In my view, the JDEE's greatest deficiency in this Paul regard is in debugging support. I would have to agree with this. For many years I have used Java quite happily without a debugger, and, of course, its quite feasible to do this. But recently I spent 5 months writing perl. Now this is a language which its nearly impossible to write without a debugger. Coming back to Java, I find that I miss it quite a bit. Phil
ECB 1.92 released!
ECB 1.92 is released! = Reminder: The homepage of ECB has moved to http://ecb.sourceforge.net http://ecb.sourceforge.net . The old homepage at http://home.swipnet.se/mayhem/ecb.html http://home.swipnet.se/mayhem/ecb.html is not longer supported. How to get it: -- Sorry, it's too big to post the sources here... If you are using ECB = 1.80 then you can just call M-x ecb-download-ecb if you are online. ECB will then download latest ECB (1.92) and install it for you. Or go to the homepage at http://ecb.sourceforge.net http://ecb.sourceforge.net and download it from there. What's new in 1.92: --- This release fixes some small bugs and introduces some new features for layout-handling. Here are the entries of the NEWS (was HISTORY) file: ** Fixed bugs: *** Fixed small bugs in the popup-menu of the history-buffer. *** Fixed some not working links in the FAQ. ** ECB now includes a file ecb-autoloads.el which contains all available autoloads of ECB. Therefore loading this file is enough. ** Enhancements to the layout *** The sizes of the ecb-windows can be fixed even during frame-resizing This new feature is only available with GNU Emacs 21.X. See new option `ecb-fix-window-size'. Suggested by Gunther Ohrner [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *** The command `ecb-store-window-sizes' can now also store fixed sizes. If called with a prefix arg then fixed sizes are stored instead of fractions of frame-width resp. -height. *** The command `split-window' is now also adviced to work properly. ** Enhancements for the tree-buffers *** Create Source in the popup-menues now work also for non-java-files. *** ecb-truncate-lines can now be set different for each ECB-tree-buffer. *** Easy horizontal mouse-scrolling of the ECB tree-buffers. See new option `ecb-tree-easy-hor-scroll'. ** Added a command `ecb-jde-display-class-at-point' which displays the contents of the java-class under point in the methods-buffer of ECB. ** Renamed previous HISTORY file to NEWS and reformate it for outline-mode. Here are some of the new features of ECB beginning with version 1.90: * Fixed an annoying bug which results in an error Wrong type argument: integer-or-marker-p nil) after a full buffer reparse. ECB 1.80 has repaired its internal state but nevertheless the user had to reclick on the same token after this error to really jump to a token. With ECB 1.90 this bug has been gone. * Now ECB displays at every start a Tip of the day in a dialog-box. This can be switched off with option `ecb-tip-of-the-day'. * New feature: Now the methods buffer is auto. expanded if the node related to the current token in the edit-window is not visible (probably because its parent is collapsed). * New command `ecb-expand-methods-nodes' which allows precisely expanding tokens with a certain indentation-level. * Rewritten the mechanism for storing customized window-sizes. See option ecb-layout-window-sizes and the command ecb-store-window-sizes and ecb-restore-window-sizes. Now the sizes are always saved as fractions of the width (resp. height) of the ECB-frame, so the stored sizes are always correct regardless of the current frame-size. * Rewritten cache-mechanism for directories and sources: This results in a speed-boost for big-size directories. * Added a complete new section The layout-engine of ECB to the online-help which describes in detail how to program new layouts and new special windows. * Fixed some bugs concerning the eshell-integration. * Speedbar is now integrated in ECB and can be used instead of the standard ECB-directories buffer. * Naming and managing of layouts has been changed! Now a layout is not longer identified by an integer but by an arbitrary string! Example: The layout with index 0 in ECB = 1.80 is now named left1 in ECB 1.90. Therefore the name of the option 'ecb-layout-nr' has changed to 'ecb-layout-name'! See the docstring of 'ecb-layout-name' for the names of all buildin layouts. ECB autom. upgrades the old-option to the new one! * A lot of new hooks * Adding a new layout type left-right which allows the ECB-tree-windows to be located at the left and the right side of the ECB-frame. * Now ECB can be autoloaded. * Now ECB offers a command `ecb-create-new-layout' for interactively creating new layouts by example. Enjoy, Klaus Klaus Berndl mailto: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] sdm AG http://www.sdm.de/ http://www.sdm.de software design management Thomas-Dehler-Str. 27, 81737 München, Germany Tel +49 89 63812-392, Fax -220
ECB + JDE window focus bug.
Hi, When I use 'jde-import-find-and-import' in ECB with a compile window, the prompt window that asks for clarification pops up in the compilation buffer. This is fine. But then, it doesn't have an idea where to put the import statement. Is there a setting in JDE/ECB that I can tweak to correct this? Recreate Problem: 1. emacs -q 2. setup loadpaths 3. load jde, ecb 3. find asdf.java 4. customize ecb-layout to use a compilation window. 5. ecb-activate. 6. With adsf.java in edit window, and focus in same window, do `jde-import-find-and-import' 7. Import ParseException class, choose any of the choices, click ok 8. Now the import statement is in my scratch buffer. Thanks. -- Le __ Post your free ad now! http://personals.yahoo.ca
Re: Why the JDEE?
Ralph Jorre writes: I don't often use a debugger but I have found JSwat very good and I just wonder if it wouldn't be more efficient to just include some hooks so as to be able to incorporate it efficiently. Maybe this would be easier to maintain than rewriting the debug. I plan to look into this. The problem is that the task of writing an Emacs front-end to JSwat may outway the advantage of replacing JDEbug with JSwat as the backend. In other words, there already exists a Lisp frontend to JDEbug. So it comes down to whether it makes more sense for me to spend my time on creating a frontend for JSwat or fixing the problems with JDEbug. Complicating the decision is the fact that I have created a generalized object-oriented debugger frontend, based on eieio. I decided to do this because jdb and the JDEbug frontends have a lot in common, e.g., essentially the same code for stepping and setting, recording, and displaying breakpoints. The generalized frontend allows both backends to inherit any improvements to the front end. I have already ported jdb to use the generalized frontend and am in the process of porting the JDEbug frontend to the generalized front end. It is conceivable that the generalized JDEE frontend could ultimately support three backends: jdb JDEbug JSwat In fact, I would prefer this as I believe there is value in having a backend that is tuned to the JDEE plus support for alternative backends as backups or to cater to user preferences for those backends. My preference would be for somebody other than myself to take on the task of creating a JDEE frontend to JSwat's console mode. This would free me to concentrate on the generalized frontend and on fixing the JDEbug backend. Developing a JSwat frontend basically entails subclassing the JDEE's generalized debugger frontend (see jde-db-debugger class) to support JSwat's console commands. This should be a fairly straightforward task. I'd be glad to serve as a consultant to anyone who wants to undertake this project. - Paul
RE: Syntax error indication oon the fly....the beginning...
Klaus, Thanks for your enhancements. I am a beginner lisp programmer (which may have been revealed by my long winded coding style and indentation and incomplete knowledge of what is already available in base emacs packages). Where I want to take this idea is to: 1. Run a background compilation (during idle times) using JDEE compilation server. A similar behavior could be hooked up to the compilation finish hook. 2. Indicate the error messages using an underline (or user customizable) face (say!) over the extent of the buffer text causing the error. (unfortunately not all compilers give the column or column range where the error is). 3. User can get details of the error message with mouse-over or some key combination (I need to check if 'help-echo text property will work for that). 4. Provide a popup menu of possible actions user could take to correct the error e.g. i. importing a type ii. inserting a parenthesis or a semicolon etc. (This is to take care of quickly fixing the errors which most modern compilers diagnose very well). I will keep working at it...no promises though as to when I will be able to have something working... -sandip -Original Message- From: Klaus Berndl [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 2:34 AM To: [EMAIL PROTECTED] Subject: Re: Syntax error indication oon the flythe beginning... Hi Sandip, a really nifty idea which could be enhanced with a general package - i have written long time before - to highlight not only the current error in the compilation-buffer (like the standard compile.el package does) but also the related code-line in the source-buffer. Your nifty idea (but somehow long winded code) could be written much smaller if using in combination with my package - see below. First here comes a rewritten version of your function: , | (defun animate-compilation-messages1 () | (interactive) | (if compilation-last-buffer | (let ((number-of-errors (length (save-excursion | (set-buffer compilation-last-buffer) | compilation-error-list | (dotimes (i number-of-errors) | (next-error) | (sit-for 3)) | (message Done ` This displays the error-message not in the echo-area but walks through the compilation-buffer itself. But maybe this should be made customizable because displaying the error-message in the minibuffer or as tool-tip can make sense if the compilation-window has been deleted to get more space for the source-buffer?! So the code could first check if the compilation-window is visible Anyway, here comes the code which enables highlighting (customizable! See option compilation-highlight-source a.o.) both error-message and related code-line: , | ;; enhancement of next-error: with this advice it highlights the | error-line in ;; the sourcebuffer. (defvar compilation-source-overlay | (make-overlay 1 1) | Internal overlay used for the source-line in the source-buffer) | | (defcustom compilation-highlight-source '(secondary-selection . any-command) | *If not nil then highlight the source-line in the source-buffer. | Then you must define the face for the source-line and when the | unhighlighting of the source-line should be done. The value is either | nil or a cons where the car is the face for the source-line and the | cdr is one of the following symbols: | - any-command: Any command will unhighlight the source-line \(default) | - window: Any command that scrolls the source-line outside the visible | portion of the buffer will unhighlight it | - line: Any command that moves point out of the source-line | unhighlights it. | - after-change: The first buffer-change will unhighlight the source-line. | :group 'compilation | :set '(lambda (symbol value) | (set symbol value) | (if (and (consp value) (or (featurep 'xemacs) | (facep (car value | (overlay-put compilation-source-overlay 'face (car value | :type '(radio (const :tag No highlighting of source-line :value nil) | (cons :tag Highlight source-line | (face :tag Face for the highligthing) | (radio :tag Unhighlight source-line | (const :tag After any command | :value any-command) | (const :tag After scrolling out of the window | :value window) | (const :tag After moving point out of the source-line | :value line) | (const :tag After first change in the buffer | :value
Re: Why the JDEE?
I had thought of this as well. Perhaps the JSwat maintainer would be interested in working on it. If you download the JSwat CVS code, you see they arleady use JDEE. See: http://home.nc.rr.com/nascifandelaine/jswat.el Paul Kinnucan [EMAIL PROTECTED] writes: Ralph Jorre writes: I don't often use a debugger but I have found JSwat very good and I just wonder if it wouldn't be more efficient to just include some hooks so as to be able to incorporate it efficiently. Maybe this would be easier to maintain than rewriting the debug. I plan to look into this. The problem is that the task of writing an Emacs front-end to JSwat may outway the advantage of replacing JDEbug with JSwat as the backend. In other words, there already exists a Lisp frontend to JDEbug. So it comes down to whether it makes more sense for me to spend my time on creating a frontend for JSwat or fixing the problems with JDEbug. Complicating the decision is the fact that I have created a generalized object-oriented debugger frontend, based on eieio. I decided to do this because jdb and the JDEbug frontends have a lot in common, e.g., essentially the same code for stepping and setting, recording, and displaying breakpoints. The generalized frontend allows both backends to inherit any improvements to the front end. I have already ported jdb to use the generalized frontend and am in the process of porting the JDEbug frontend to the generalized front end. It is conceivable that the generalized JDEE frontend could ultimately support three backends: jdb JDEbug JSwat In fact, I would prefer this as I believe there is value in having a backend that is tuned to the JDEE plus support for alternative backends as backups or to cater to user preferences for those backends. My preference would be for somebody other than myself to take on the task of creating a JDEE frontend to JSwat's console mode. This would free me to concentrate on the generalized frontend and on fixing the JDEbug backend. Developing a JSwat frontend basically entails subclassing the JDEE's generalized debugger frontend (see jde-db-debugger class) to support JSwat's console commands. This should be a fairly straightforward task. I'd be glad to serve as a consultant to anyone who wants to undertake this project. - Paul
Re: Why the JDEE?
On Fri, 21 Feb 2003, [EMAIL PROTECTED] wrote: It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. Maybe to further this, create an email list called, jde-plugin, or something like it. Then, as people want to discuss this idea and try to make Emacs have an architecture to keep up with the other IDE's, you can monitor and consult on the direction but not feel compelled to answer the direct questions to this particular list. And, when questions of this sort hit the jdee list, we can point them to this particular branch of JDEE discussion. We, as users, can also feel that we won't be going against your wishes as to the focus of the jdee, and hence, the jdee mailing list itself. -- Galen Boyer
managing imports
Hi all, I have some questions about managing imports in JDEE. 1. I see that there is a very nice `jde-import-organize' and `jde-import-collapse-imports' functions. But what if I want to expand an import of java.util.* to only classes that I'm using? 2. In WSAD, when I organize imports, it wants to expand the imports, while JDE offers functions (that I can find) that gear itself to collapsing imports. Why? Many thanks. -- Le __ Post your free ad now! http://personals.yahoo.ca
managing imports
Le Wang writes: Hi all, I have some questions about managing imports in JDEE. 1. I see that there is a very nice `jde-import-organize' and `jde-import-collapse-imports' functions. But what if I want to expand an import of java.util.* to only classes that I'm using? 2. In WSAD, when I organize imports, it wants to expand the imports, while JDE offers functions (that I can find) that gear itself to collapsing imports. Why? Because nobody has ever felt enough of a need to develop a command to expand a package-level import statement. Personally I always import by class rather than package. If I need to update a file that has package imports, I delete the package imports, compile the file, then use the compile buffer error messages to jump to the first unimported symbol, type C-c C-v C-z to import it jump to the next unimported symbol, C-c C-v C-z, to import it and so on. People have suggested adding a command to import all class symbols in a file that are not already imported. I think this is a good idea but have never felt sufficiently motivated to write it, nor has anyone else so far as I know. - Paul
RE: managing imports
-Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 12:15 PM To: Le Wang Cc: [EMAIL PROTECTED] Subject: managing imports --8-snip8- People have suggested adding a command to import all class symbols in a file that are not already imported. I think this is a good idea but have never felt sufficiently motivated to write it, nor has anyone else so far as I know. No. I had written a BCEL based tool to parse a class file and dump the imports. Nick Sieger had wrapped it in some lisp code also. Somehow the idea never took hold. Please see this thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01127.html
RE: managing imports
--- Chitale, Sandip V [EMAIL PROTECTED] wrote: No. I had written a BCEL based tool to parse a class file and dump the imports. Nick Sieger had wrapped it in some lisp code also. That's pretty ingenious. But does anyone think this should be possible without parsing a compiled class file? If someone can give me some pointers I'll work on this. -- Le __ Post your free ad now! http://personals.yahoo.ca
Re: Why the JDEE?
Galen Boyer writes: On Fri, 21 Feb 2003, [EMAIL PROTECTED] wrote: It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. Maybe to further this, create an email list called, jde-plugin, or something like it. Then, as people want to discuss this idea and try to make Emacs have an architecture to keep up with the other IDE's, you can monitor and consult on the direction but not feel compelled to answer the direct questions to this particular list. And, when questions of this sort hit the jdee list, we can point them to this particular branch of JDEE discussion. We, as users, can also feel that we won't be going against your wishes as to the focus of the jdee, and hence, the jdee mailing list itself. I was only explaining where I intend to focus my efforts personally for the immediate feature. I welcome others working on features that interest them personally. A number of people are already doing this and are updating the JDEE CVS repository independently of myself. I would be glad to give anyone else access to the JDEE CVS repository who can demonstrate the necessary skill level and commitment to quality. - Paul
Re[2]: Syntax error indication oon the fly....the beginning...
Chitale, Sandip V [EMAIL PROTECTED] seems to think that: [ ... ] 2. Indicate the error messages using an underline (or user customizable) face (say!) over the extent of the buffer text causing the error. (unfortunately not all compilers give the column or column range where the error is). 3. User can get details of the error message with mouse-over or some key combination (I need to check if 'help-echo text property will work for that). [ ... ] Hi, I bumped into this thread a little late I guess. I had a plan to do this with a fancy utility of mine, but never got around to it. I brushed off the old plan and hacked it together. Your mileage may vary, but it is working well in grep buffers at the moment. It requires EIEIO to get the linemark package which any good JDEE user should have. Hopefully it doesn't require the CVS version of linemark.el for Emacs. I think I avoided those features. I cannot vouch for its usefulness on XEmacs as the release version of linemark has an odd face related bug, and lmcompile is using 'help-echo to do the mouse-overs. That's what you get for quick hack I guess. To use it, perform a grep or compile, and use `lmcompile-do-highlight'. Sick of it, use `lmcompile-clear'. Because it uses the `linemark' package at it's core, you set up the highlights once, and the linemark harness handles keeping all the overlays up to date as you load different files in and out of memory. The below is just a harness of what can be done with linemark. I've adapted linemark for specialized tasks to great effect on other projects, so there are many more possible features that could be added. See the visual studio bookmark look alike at the end of linemark.el for examples. This functionality has little to do with what was already posted. It is tackling the problem from a completely different angle. Enjoy Eric - ;;; lmcompile.el --- highlight compile error lines ;; ;; Author: Eric M. Ludlam [EMAIL PROTECTED] ;; Maintainer: Eric M. Ludlam [EMAIL PROTECTED] ;; Keywords: lisp ;; ;; Copyright (C) 2003 Eric M. Ludlam ;; ;; 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 GNU Emacs; see the file COPYING. If not, write to ;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. ;; ;;; Commentary: ;; ;; This package uses the compile package, and the linemark package to ;; highlight all lines showing errors. ;;; Commentary: ;; (require 'linemark) ;;; Code: (defclass lmcompile-linemark-group (linemark-group) ( ) Linemark Group for compile error highlights.) (defclass lmcompile-linemark-entry (linemark-entry) ((errormarker :initarg :errormarker :type marker :documentation Marker pointing to the source of the match.)) Linemark Group for one compile error highlight. Tracks additional information about the error.) (defmethod linemark-new-entry ((g linemark-group) rest args) Create a new entry for G using init ARGS. (let ((f (plist-get args :filename)) (l (plist-get args :line))) (apply 'lmcompile-linemark-entry (format %s %d f l) args))) (defmethod linemark-display ((e lmcompile-linemark-entry) active-p) Set object E to be active or inactive. ;; A bug in linemark prevents individual entry colors. ;; Fix the color here. (when active-p (condition-case nil (save-excursion (set-buffer (marker-buffer (oref e errormarker))) (goto-char (oref e errormarker)) (let ((face (cond ((re-search-forward error (point-at-eol) t) 'linemark-stop-face) ((re-search-forward warning (point-at-eol) t) 'linemark-caution-face) (t 'linemark-funny-face (oset e :face face) )) (error nil)) ) ;; Do the rest of our work (call-next-method) ;; Add a tool tip (when (and active-p (slot-boundp e 'overlay) (oref e overlay)) (let ((em (oref e errormarker)) (txt nil)) (condition-case nil (save-excursion (set-buffer (marker-buffer em)) (goto-char em) (setq txt (buffer-substring-no-properties (point-at-bol) (point-at-eol))) ) (error nil)) (when txt (linemark-overlay-put (oref e overlay)
