Re: Why the JDEE?
Paul, For what it's worth, I absolutely agree with you on the need for debugging support. I still follow the JDEE mailing list but I had to drop JDEE for Eclipse almost a year ago because of the lack of debugging support ... I can live with it on a small project, but on a large project (esp. when using Swing) JDEE really needs better means of debugging. Having said that, thanks for bringing JDEE to the world and it's continued enhancement. Milan On February 21, 2003 03:30 pm, Paul Kinnucan wrote: Dear JDEE Users, A number of recent threads have alluded to the need for the JDEE to keep pace, featurewise, with the competition, e.g., Eclipse and JBuilder. I'd like to present my perspective on this issue as the JDEE's lead developer and maintainer. It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. The reason is that the pure Java IDEs do not face the difficult skills and architectural constraints than the JDEE development team faces, e.g., JDEE development requires both Emacs Lisp and Java skills and is constrained to standard I/O for interprocess communications. Why then bother with the JDEE? Because it allows Emacs users to use Emacs to develop Java code. Put another way, the reason for choosing the JDEE will always be Emacs and not the other way around. The JDEE allows Emacs users to make the transition to Java development without having to learn another environment. It also allows users who are, like myself, working in a multilanguage environment (e.g., C/C++/Java) to use a single environment for all their work. Where then should the JDEE development team focus its efforts. The focus should be on those features that best ensure that a decision to use Emacs for Java development does not entail a loss of productivity compared to what other environments afford. In my view, the JDEE's greatest deficiency in this regard is in debugging support. Therefore, it is my intention to focus my efforts personally in this area with the goal of providing the JDEE ASAP, not with the best debugger available, but at least one that does the basics well and reliably. Until then, other features that have been mentioned recently, such as a plugin architecture and syntax errors on the fly, will move forward only in so far as others work on them. Regards, Paul
Re: Why the JDEE?
I agree, although I personally don't really care for #4. I would add that displaying variables on a large object tree may be extremely slow if data are being sent between emacs and java. Milan On February 21, 2003 03:41 pm, Chitale, Sandip V wrote: I agree with you. In terms of features in debugger I would like to see - 1. fast update to different views 2. better variables view (I would like to suggest Java based GUI for this i.e. a treetable) 3. storing and managing breakpoints 4. breakpoint grouping 4. Different kinds of breakpoints i. conditional breakpoints ii. actions when the breakpoints are hit iii. method entry breakpoint (JPDA allows this) iv. method exit breakpoint a. normal exit b. abnormal exit (exception) c. ability to see return value on the stack (even if it was not stored in some local variable). I am not sure if JDPA allows this. v. Class loading breakpoint Just my wish list. -sandip -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 12:30 PM To: [EMAIL PROTECTED] Subject: Why the JDEE? Dear JDEE Users, A number of recent threads have alluded to the need for the JDEE to keep pace, featurewise, with the competition, e.g., Eclipse and JBuilder. I'd like to present my perspective on this issue as the JDEE's lead developer and maintainer. It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. The reason is that the pure Java IDEs do not face the difficult skills and architectural constraints than the JDEE development team faces, e.g., JDEE development requires both Emacs Lisp and Java skills and is constrained to standard I/O for interprocess communications. Why then bother with the JDEE? Because it allows Emacs users to use Emacs to develop Java code. Put another way, the reason for choosing the JDEE will always be Emacs and not the other way around. The JDEE allows Emacs users to make the transition to Java development without having to learn another environment. It also allows users who are, like myself, working in a multilanguage environment (e.g., C/C++/Java) to use a single environment for all their work. Where then should the JDEE development team focus its efforts. The focus should be on those features that best ensure that a decision to use Emacs for Java development does not entail a loss of productivity compared to what other environments afford. In my view, the JDEE's greatest deficiency in this regard is in debugging support. Therefore, it is my intention to focus my efforts personally in this area with the goal of providing the JDEE ASAP, not with the best debugger available, but at least one that does the basics well and reliably. Until then, other features that have been mentioned recently, such as a plugin architecture and syntax errors on the fly, will move forward only in so far as others work on them. Regards, Paul
Syntax error indication oon the fly....the beginning...
Folks, I had brought up this issue earlier...I took a first crack at it. It is still rough but with some expert help this could be completed... Especially I need help with save-excursion and buffer selection etc... For now - 1. Compile any java class such that it results in error messages 2. Switch to the *compilation* buffer 3. Invoke the following function animate-messages (defun animate-messages() Animate messages in *compilation* buffer. (interactive) (let* ( (errorMarker (compilation-next-error-locus 1 t t)) (compilation-error-overlay) ) (while errorMarker (let ( (nextErrorMarker (compilation-next-error-locus 1 nil t)) (errorBufferMarker (car errorMarker)) errorString errorBegin errorEnd ) (save-excursion (setq errorBegin (marker-position errorBufferMarker)) (if nextErrorMarker (setq errorEnd (marker-position (car nextErrorMarker))) (setq errorEnd (point-max)) ) (setq errorString (buffer-substring errorBegin errorEnd)) ) (save-excursion (if (not (eq (current-buffer) (marker-buffer (cdr errorMarker (switch-to-buffer (marker-buffer (cdr errorMarker))) ) (goto-char (marker-position (cdr errorMarker))) (if compilation-error-overlay (move-overlay compilation-error-overlay (line-beginning-position) (line-end-position)) (setq compilation-error-overlay (make-overlay (line-beginning-position) (line-end-position))) ) (overlay-put compilation-error-overlay 'face 'underline) (message errorString) (sit-for 3) ) (setq errorMarker (compilation-next-error-locus 1 nil t)) ) ) (if compilation-error-overlay (delete-overlay compilation-error-overlay) ) (message Done.) ) ) [NOTE: The above works for grep output also.] 4. This should animate the error messages i.e. i. move the point to the location of error ii. temporarily underline the line iii. echo the error message in mini-buffer What I want to do eventually is to hook this function to compilation finish hook. When there are compilation error messages the error messages are shown in the buffer with some overlay. The help-echo text property is used to show the error meesage in mini-buffer. A background compilation may be invoked every so often or on demand basis... enjoy, sandip
Missing buttons
I just built Xemacs 21.4.12 and now I can't see the buttons that appear when a choice of classes results from the function, jde-import-find-and-import (C-c C-v C-z). I see other buttons, e.g. toolbar and customize, just not those. What build option might I have left out to cause that? Thanks -- Jim Crossley http://crossleys.org/~jim 404.409.9085
Questions from a newguy
Chris writes: My problems with whitespace are that 1) I have no control over it -- I don't ever want to hit Tab and have nothing happen, 2) I don't know how to customize it, and 3) it looks like Emacs is not saving tabs as tabs (even though I thought I told it to), so that I can't pleasantly edit files that have been touched by Emacs. I'm not looking for quick fixes / code samples here; I'm willing to do some work, but I'm having a hard time getting started. By the way, Gnu sells a Introduction to Emacs Lisp Programming (I think), that's only available online. I can get by in Lisp, and I've read the online reference manual, but it's a little dry. Indentation of Java source code is handled by an Emacs package called cc-mode. cc-mode is very powerful but not very user friendly. If you're really serious about using Emacs to do software development, you'll need to make the effort to master cc-mode. Start by studying the cc-mode documentation that comes with Emacs. All cc-mode indentation options are settable via Lisp variables. If you can write a setq statement, you know all the Lisp you need to know to use cc-mode. Better yet, use Emacs' customize-variable command to avoid writing any Lisp. Finally, you should make a practise of including your .emacs file when asking for help. An .emacs file tells a would-be helper what you really told Emacs as opposed to what you thought you told Emacs. - Paul
