jde-gen-get-set and variable creation position
Title: jde-gen-get-set and variable creation position Hi, I like the jde-gen-get-set functionality, but some of its the details get in the way every now and then. I constantly find myself correcting the output. Here is why: - it creates the variable declaration in the middle of the code. As a matter of style, it would be better to create it either at the beggining or the end of the class. Kinda like the jde-import functionality. - It could check if the variable already exist and skip the variable declaration if that is the case. I guess these enhacements would require extensible changes... :-) - the javadoc tags generated do not follow the same style of the jde-javadoc commands changing the template would do the trick? Regards, Nascif -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 5:05 PM To: Len; [EMAIL PROTECTED] Subject: Re: Other beanshell versions? At 10:41 AM 3/1/01 +1300, Len wrote: Hi, I notice that the version of beanshell distributed with jde is a bit behind the most recent stable version at www.beanshell.org. What's the easiest way to upgrade it: is it just as simple as dropping a new bsh.jar into the jde lib directory, or are there customizations to the You can do that. It should work unless the latest version has introduced incompatibilities with Emac as have previous versions. version distributed with jde that would cause a malfunction if I tried to use the standard bsh distribution (the mention of JDE Patch in the Which version of the JDE are you using. The current version use beanshell 1.0 beta unpatched. beanshell startup message makes me wonder). There are extras in the new version that I'd like to use, but don't want to break jde. The patch was needed to fix the Beanshell's command line interface which used a java.io method that did not work correctly in JDK 1.1.x. The problem occurred only if you were running JDK 1.1.x. Anyway I believe the problem was fixed in subsequent versions. Side note: It does seem a little inconsistent that jde requires a few external lisp packages but comes with a version of beanshell. I'm just interested why there's the distinction. Just history. I developed beanshell.el specifically for the JDE but with the idea of ultimately spinning if off as an independent package (hence the name). Unfortunately, I built some dependencies on the JDE into the current version of beanshell.el and I have to date not had the time or incentive to eliminate the dependencies and post it as an independent package. - Paul
RE: Patch to allow use of remote JavaDoc docsets
Title: RE: Patch to allow use of remote JavaDoc docsets Thanks for the useful patch! FYI, A port of wget for Windows can be downloaded from http://www.interlog.com/~tcharron/wgetwin.html Cheers, Nascif -Original Message- From: Adrian Robert [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 10:17 PM To: [EMAIL PROTECTED] Subject: Patch to allow use of remote JavaDoc docsets Hi all, Two issues with JavaDoc display for symbols (C-c C-v C-w). First, if you select Other when customizing 'jde-help-docsets' instead of javadoc, lookup will fail (at least on emacs 20.7.1 on Linux) because the 'apply' built-in expects a list as its last argument. (See patch below.) Second, at my company we store JavaDoc for the software we develop on an internal server and I didn't want to copy it to my machine. So here is an initial stab at providing support for remote JavaDoc accessible through http. It only works on systems where the 'wget' utility is available. Most linux systems come with it by default. Cygwin for Windows doesn't, but it may exist. I'm not sure about others... 1) Insert the following into .emacs: ; find the html file for a class in a local or remote javadoc tree (defun javadoc-find (class docset-dir) (let ((doc-path (concat docset-dir / (substitute ?/ ?. class) .html))) (if (or (file-exists-p doc-path) (and (string-match http: doc-path) (string-match 200 (shell-command-to-string (concat wget --spider doc-path) doc-path) )) 2) Apply the patch below sitting in the JDE top level directory with patch -p0 jde-help-patch.patch (or whatever filename). It affects lisp/jde-help.el, and fixes both the Other bug mentioned above (first chunk) and adds the capability to use a remote JavaDoc docset by NOT prepending file:// to the name if it starts with http: or file: already (second chunk). You'll need to remove the jde-help.elc file and recompile it if you've already compiled jde. The patch was generated against jde-2.2.6. (I've attached it as well in case word-wrapping over email mangles it.) I suppose the javadoc-find function could be inserted directly in the jde-help.el file, but I wanted to keep the changes to the distribution file to a minimum. It works by calling 'wget' to see if the file exists remotely instead of using 'file-exists-p'. hope it's useful, Adrian patch follows --- lisp/jde-help.el Fri Mar 9 17:45:15 2001 +++ lisp/jde-help-new.el Fri Mar 9 17:44:48 2001 @@ -120,7 +120,7 @@ (apply (jde-help-docset-get-lookup-function docset) class - (jde-help-docset-get-dir docset) + (list (jde-help-docset-get-dir docset)) jde-help-docsets))) (setq paths (delq nil paths)) ;; Return first file found. @@ -171,9 +171,12 @@ (defun jde-help-show-document (doc-file) - Actually displays the document. + Actually displays the document, prepending 'file://' if it appears to be local. (if (not (eq doc-file nil)) - (browse-url (format file://%s doc-file + (cond + ((or (string-match http: doc-file) (string-match file: doc-file)) + (browse-url doc-file)) + (t (browse-url (format file://%s doc-file )) (defun jde-help-choose-document(doc-files) Allows the user to select which of the possible documentation files they wish to view.
font lock for local variables
Title: font lock for local variables Hi, Just wondering, would it be possible to use the JDE semantic knowledge about a Java file to assign a font lock specifically for local variables? This would be wonderful to catch those situations where you create a local variable that eclipses a class data member, and end up making an update that loses effect as soon as the scope is closed... Naming conventions help, but if you're reading someone else's code that don't use them, you're out of luck! Regards, Nascif A.A. Neto -Original Message- From: Dr. Volker Zell [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 11, 2001 3:56 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Problems with experimental versions of jde and semantic Hi Steve I'm testing your experimental versions of the following packages: jde-1.25-pkg.tar.gz semantic-1.05-pkg.tar.gz eieio-1.01-pkg.tar.gz - seems to work Here a couple of problems with your versions of semantic, and jde: First of all jde-1.25-pkg.tar.gz is missing jde-package.el/elc. If I copy that from the normal jde distribution jde starts up. JDE and JDebug docu are not found through menu. This is because first, JDE docu is missing from your tar.gz file and second, the lisp code is searching for the html files under the wrong directories. This fixes the directories: diff -c /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el~ /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el *** /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el~ Sat Mar 10 23:05:58 2001 --- /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde.el Sat Mar 10 23:05:58 2001 *** *** 1289,1295 (if jde-dir (if (and jde-xemacsp (locate-data-directory jde)) ! (expand-file-name jde-ug.html jde-dir) (expand-file-name doc/html/jde-ug/jde-ug.html jde-dir) (if (and jde-help --- 1289,1295 (if jde-dir (if (and jde-xemacsp (locate-data-directory jde)) ! (expand-file-name doc/html/jde-ug/jde-ug.html jde-dir) (expand-file-name doc/html/jde-ug/jde-ug.html jde-dir) (if (and jde-help diff -c /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el~ /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el *** /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el~ Sat Mar 10 23:07:05 2001 --- /usr/local/lib/xemacs/xemacs-packages/lisp/jde/jde-bug.el Sat Mar 10 23:07:05 2001 *** *** 2569,2575 (if jde-dir (if (and jde-xemacsp (locate-data-directory jde)) ! (expand-file-name jdebug-ug.html jde-dir) (expand-file-name doc/html/jdebug-ug/jdebug-ug.html jde-dir) (if (and jdebug-help --- 2569,2575 (if jde-dir (if (and jde-xemacsp (locate-data-directory jde)) ! (expand-file-name doc/html/jdebug-ug/jdebug-ug.html jde-dir) (expand-file-name doc/html/jdebug-ug/jdebug-ug.html jde-dir) (if (and jdebug-help o Also missing is the /usr/local/lib/xemacs/xemacs-packages/etc/jde/doc/tli_rbl/ directory structure. This results in not loading the applet in the JDE help files. o The import class and implement interface wizards give errors of the following kind: Imported java.applet.Applet Invalid function: (macro . #compiled-function (token) ...(6) [token semantic-overlay-start semantic-token-overlay] 3 (/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic -util.elc . 1624)) This seems to be related with the byte compilation of semantic. It used to work with semantic when it's not byte compiled. Anyway both commands produce the desired output but the error messages are annoying. Ciao Volker
RE: Should the JDE require ECB?
Title: RE: Should the JDE require ECB? Hi Paul, Great idea, I think that there is a lot of synergy to explore between JDE and ECB. Besides the integration with the project variables (for source directories and other parameters) I think that there is a lot to gain as well in the use of the windows layout engine by JDEbug. Thanks, Nascif -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 12, 2001 1:02 AM To: [EMAIL PROTECTED] Subject: Should the JDE require ECB? Hi all, I have come to rely on the Emacs Code Browser (ECB) and would like to integrate it into the JDE. This would entail making ECB yet another external package required by the JDE. The benefit, however, is that the JDE would provide facilities for using ECB, such as keybindings and menu items for toggling ECB off-and-on and setting up ECB to browse jde-db-source-directories. What do you think?
Turning off mouse hooks on ECB
Title: RE: Line Wrap problems with ECB Hi, I've been using ECB a lot w/ JDE. Typically I activate and deactivate it many times during an Emacs session (to take a better look at shell buffers, dired windows, etc.), and have even created keybinds for that (below). The problem is, ecb-deactivate don't seem to do a complete clean-up, specially in the mouse hooks. After I activate/deactivate ECB I start to have very strange mouse (the so called "jump to right destination" behavior, I believe) and frame (popping up) behavior. Is there anyway to configure ECB to *really* deactivate the additional mouse/frame behavior? Regards, Nascif ;; ECB keybindings(global-set-key "\C-cea" 'ecb-activate)(global-set-key "\C-ced" 'ecb-deactivate)(global-set-key "\C-ceu" 'ecb-update-directories-buffer)(global-set-key "\C-cec" 'ecb-current-buffer-sync)(global-set-key "\C-cem" 'ecb-rebuild-methods-buffer)(global-set-key "\C-cel" 'ecb-redraw-layout)(global-set-key "\C-cec" 'ecb-clear-history)(global-set-key "\C-ceh" 'ecb-show-help)
RE: Turning off mouse hooks on ECB
Title: RE: Turning off mouse hooks on ECB Klaus, I'm using the latest official version, 1.32. I'll check the toggle-visibility command and the latest version; but I think I really want to keep using deactivate in order to remove the mouse and frame hooks. They don't make sense when you're doing non-code related activities (like working in the shell, playing with dired, e-mail, etc.) Regards, Nascif -Original Message- From: Berndl, Klaus [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 05, 2001 11:33 AM To: Abousalh-Neto, Nascif [NCRTP:3S60:EXCH]; 'JDE'; 'ECB-Mailing List' Subject: RE: Turning off mouse hooks on ECB First: I will inspect the code carefully where not a cleanup is done because this should be done otherwise it is a bug. But second: Which version of ecb you are using? I suppose something = 1.32?! Ok, latest 1.40beta2 version which is available via CVS has a lot of improvements: here is the HISTORY-file. You see, there are menus, keybindings, minor-modes etc. AND there is a toggle-visibilty-ecb-windows command. Therefore you should not activate/deactivate ECB but only toggle the visibility of the ecb-windows. But this works only with latest 1.40beta2. maybe we should realease soon 1.40?! Klaus HISTORY: Version 1.40: - - New advice for 'other-window-for-scrolling', so all scroll-functions for the other window can also scroll the first edit-window if point stays in the second one. (Klaus) - ecb-toggle-ecb-windows now preserves the split, the split-amount, the buffer contents, the window starts and current point. (Klaus) - Some important changes in the ECB-layout concerning displaying compilation- and temp-buffers. (Klaus): + 'ecb-select-compile-window' has been gone. + 'ecb-use-dedicated-windows' is not longer a user-customizable option but it is always set to t, because this is essential for correct working of the ecb-layout engine! + 'ecb-compile-window-temporally-enlarge' is now a boolean option. + Now ECB does all necessary that your edit-window of ECB seems to be a normal Emacs frame, especially concerning displaying temp-buffers (like help- and completion-buffers) and compilation-buffers. + The variables 'compilation-window-height' and 'temp-buffer-shrink-to-fit' (XEmacs) and 'temp-buffer-resize-mode' (GNU Emacs) are now fully supported by ECB if no durable compilation-window is shown. - New function to toggle visibility of the ECB windows. Now it´s possible to hide all ECB windows without deactivating ECB (see 'ecb-toggle-ecb-windows') (Klaus). - ECB is now a global minor mode with it´s own menu ECB and it´s own keymap with prefix C-c .. New function to (de)activate/toggle ECB with 'ecb-minor-mode'. (Klaus) - Fixed a bug in highlighting current token in the method-buffer when font-lock-mode is nil for the source-buffer. (Klaus) - New option for highlighting the method-header in the edit-window after clicking onto the method in the method-window (like Speedbar does). (Klaus) - Function for automatically submitting a problem report to the ECB mailing list: ecb-submit-problem-report. (Klaus) - Now not only for method-highlighting an idle delay can be set but also for synchronizing the ECB windows with current edit window (see option ecb-window-sync and ecb-window-sync-delay; default is 0.25 sec delay) (Klaus). - Smarter highlighting of current method (Klaus). - All tree-buffers now have as default-directory the current selected directory in the directory buffer. So you can also open files with find-file etc. from within the tree-buffers. (Klaus). Hi, I've been using ECB a lot w/ JDE. Typically I activate and deactivate it many times during an Emacs session (to take a better look at shell buffers, dired windows, etc.), and have even created keybinds for that (below). The problem is, ecb-deactivate don't seem to do a complete clean-up, specially in the mouse hooks. After I activate/deactivate ECB I start to have very strange mouse (the so called jump to right destination behavior, I believe) and frame (popping up) behavior. Is there anyway to configure ECB to *really* deactivate the additional mouse/frame behavior? Regards, Nascif ;; ECB keybindings (global-set-key \C-cea 'ecb-activate) (global-set-key \C-ced 'ecb-deactivate) (global-set-key \C-ceu 'ecb-update-directories-buffer) (global-set-key \C-cec 'ecb-current-buffer-sync) (global-set-key \C-cem 'ecb-rebuild-methods-buffer) (global-set-key \C-cel 'ecb-redraw-layout) (global-set-key \C-cec 'ecb-clear-history) (global-set-key \C-ceh 'ecb-show-help)
RE: JDE and Transmogrify (was RE: jlint, antic or other code clea ning tools)
Title: JDE and Transmogrify (was RE: jlint, antic or other code cleaning tools) Hi Guillaume, -Original Message-From: Guillaume Berche [mailto:[EMAIL PROTECTED]]Sent: Monday, August 06, 2001 3:44 AMTo: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; Mark MynstedCc: jdeSubject: RE: JDE and Transmogrify (was RE: jlint, antic or other code cleaning tools) The integration of Transmogrify with an IDE seems to be pretty well designed. It seems a good candidate for integration with JDE. I looked in the past at the integration of JRefactory http://jrefactory.sourceforge.net/csrefactory.html. Althought JRefactory seems more advanced in terms of refactoring features, Transmogrify makes it easier to integrate with IDEs.[Nascif]I got the same impression. I was playing with JRefactoryrecentely, andthe main designer was kind enough to extend it to allow the user to configure gnuclient as a source code viewer. This makes for anice one-direction integration; you now can, from the UML class diagram interface of JRefactory, launch Emacs to see the source code. But integration on the other direction (Emacs-JRefactory) would be much harder. Concerning the fact that the parsing is made twice and would cost in terms of performance, [Nascif]Plus the fact that Transmogrify uses a lot of memory in the short term I would rather approach the use of Transmogrify as an explicit action by the developper rather than an agent warning you constantly of improvements you could make to your code. Consequently, we can imagine to only trigger Transmogrify when the developer requires it. I would be very willing to wait a few seconds every time I need a refactoring/check done, and have no performance impact the rest of the time.[Nascif]I agree 100% percent. Consequently, the integration with Transmogrify would be emacs-driven instead of the other way around. A same stdin/stdout tunnel than the beanshell/JDEbug uses, could be used for this integration. Emacs would issue beanshell instruction to Transmogrify for triggering refactorings, and the JDE implementation of Transmogrify's Hook interface http://transmogrify.sourceforge.net/doc/api/net/sourceforge/transmogrify/hook/Hook.html would issue lisp requests to emacs and parse the results to return them to Transmogrify (such as data about current selection)[Nascif]I wonder if the BeanShell instance created by JDEbug could be re-used, shaving some seconds outof the start-up time. Having two JVMs running under Emacs/JDE will take a lot of resources... I believe it might make sense to wait a bit to have Transmogrify stabilize and expand the list of refactorings before integrating with the JDE. Transmogrify is still in beta, and lots of improvements are scheduled ahead.[Nascif]This is the pointI disagree with. I think that the earlier JDE is integrated with Transmogrify the more users we will have using it, and thus the more feedback the tool will receive. Open Source projects grow based on feedback, and more users mean a faster evolution. Who knows, we may even have advanced JDE users extending Transmogrify and implementing new refactorings - or reverse-engineering them to a Semantic-based implementation, which I still think is the ideal solution for JDE. Currently, the project lists the following refactorings: (http://transmogrify.sourceforge.net/doc/userguide.html) Rename Symbol--like Rename Variable except it (sort of) works for methods, too. Care must be taken when renaming interface or overridden methods. Extract Method Replace Temp With Query Inline Temp Pull up field [Nascif]Don't forget the lint (which can find unused variables, among other things) and codechange (which can wrap blocks in try-catch exceptions, a functionality that has already been required in the JDE mailing list) extensions as well. They are also very useful - and already available. Regards, Nascif -Message d'origine-De: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]Envoyé: vendredi 3 août 2001 19:50À: Mark MynstedCc: [EMAIL PROTECTED]Objet: JDE and Transmogrify (was RE: jlint, antic or other code cleaning tools) I was just checking the development notes, and here is what it mentions about integrating Transmogrify with other IDE's (already integrates with Forte and JBuilder): "The Hook interface If you want to plug Transmogrify into a different pure-java IDE, all you have to do is extend Hook and implement the abstract methods according to the IDEs plug-in architecture. The IDE must have a few things exposed in its plug-in architecture, but we feel these are fairly standard. cursor position position of beginning and end of the selection current file files in a project" I guess all
jde-parse?
Title: jde-parse? Is jde-parse still supported? I does not seems to work anymore; I traced to source code to a call (through Beanshell) to jde.parser.ParserMain.parseFile, but I can't find the Java source code for this class. It is not in jde.jar for sure. Regards, Nascif
RE: Extending JDE using Java (WAS: Gosling interview)
Title: RE: Extending JDE using Java (WAS: Gosling interview) -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Matt Munz writes: Nascif, I have been curious about the BeanShell since I heard about it, but haven't tried it yet. It sounds like you're familiar with it. Nacif It is easy to have a Lisp function calling a Java method, using the BeanShell; not so much to do the reverse. Is this really true? It seems to me that your BeanShell app can spit out arbitrary lisp code as a text stream that could be dynamically loaded in emacs. Can you elaborate on what specifically makes it difficult to do 2-way interactions with BeanShell apps? This is what JDE beanshell apps do now. The JDE Lisp function bsh-eval-r accepts an arbitrary string of Java code as an argument, e.g., invocation of a static method defined by a JDE app, and sends it to the Beanshell's standard input. It then suspends Emacs until it receives a response from the Beanshell. bsh-eval-r assumes that the response is a Lisp form. When it receives the Lisp form, bsh-eval-r evaluates it. Although this approach is incredibly powerful, it is not generic enough. It allows an Elisp app to call a Java app, and allows that Java app to return an elisp expression for evaluation (thus affecting the JDE environment). But it does not allow the Java application to see the results of that evaluation; the elisp side of the logic would have to make an addittional call to pass back that result. It also does not address (as Paul said before) asynchronous calls. For example, what if you're trying to interface to a Java library that uses listeners/events? That goes from networks protocol libraries (packet received) to GUIs (button pushed). Also, it does not address already existing code that expects to have control of the information flux, making calls to the external container to obtain information when needed. To solve these problems you would need a true two-way communication path, meaning that somehow you would need Emacs to listen for and respond to commands from the Java side. I understand and agree with the statements that a framework like that would be really complex to implement due to the interprocess communication issues. On the other hand, the benefits are great: just look at the amount of plug-ins already written for the JBuilder Open Tools API (not to mention what is also being done for Eclipse, NetBeans, Elixir, JEdit, etc.): http://www.kylecordes.com/jbot/ http://www.borland.com/jbuilder/resources/jbopentools.html http://jbopentools.sourceforge.net/ Granted, some (maybe most) of these tools could also be ported to JDE/Emacs using plain elisp/BeanShell. But it would still require a lot of duplicated glue code that could be formalized (as Sandip suggested) to make it easier for non-Lisp programmers. Even if we forget about two-way communication capabilities for a while, having a more framework-oriented standard for adding Java extensions to JDE would be highly beneficial. JDE could have an /extensions directory where it would search for extension jar files. They would be automatically loaded at BeanShell start-up time, and appropriate menu entries/elisp wrappers would be generated using Java Reflection or a config file. When activating the extension code in response to a user command, JDE would pass to it the current environment info (file name, cursor position, text in the active region) - if two-way communication is implemented, an API would be provided to allow the Java code to ask for this information directly. There is a lot of cool stuff out there - code beautifiers, UML browsers, refactoring tools, lint tools, network protocol stacks - that could be integrated to JDE by regular Java developers *today* if only they had a framework like that. The challenge is big but so are the benefits... Regards (and sorry for yet another lengthy e-mail) Nascif - Paul
RE: OT Learning Lisp
Title: RE: OT Learning Lisp Hi Kevin, Check out the GNU Emacs Lisp Intro. There are many versions around, check this one at: http://www.gnu.org/manual/emacs-lisp-intro/html_mono/emacs-lisp-intro.html Regards, Nascif -Original Message- From: Kevin Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 9:42 AM To: Jde Subject: OT Learning Lisp I often come across features in JDE (and other Emacs libs) that I'd like to work on but my Lisp knowledge is minimal (at best). I have the Writing Emacs Extensions book, but I'm looking for a better introduction to lisp programming, preferably but not necessarily, with an Emacs slant. Any recommendations would be gratefully received. Oh and sorry for the OT post, I couldn't think of a better group to ask :-) Kevin Jones Developmentor www.develop.com
Re: Interfacing Java tools with JDEE
Title: Re: Interfacing Java tools with JDEE Hi Graham, [snip] complicated. The main problem is that emacs seems only to send data back when the socket is shutdown, so I have to continually reinitialise the socket. I think that using sockets is better that using gnuclient, since: - not all designers enable or install gnuclient; - every operation on the Java-Emacs direction will create a new process (gnuclient), and the overhead can add up; - the windows pop-ups created by gnuclient can be annoying (yes, I tried to use gnuclientw). Maybe once you share the socket code with this list the gurus could help you work out the problems :-) The main problem is communicating in the other direction, for example when the user selects a menu option. As you mentioned in your other e-mail, using the Beanshel-based jde-eval is probably the way to go here. [snip] therefore hack up the elisp end of it as well. There's no reason that the resulting elisp/java couldn't be made a bit more abstract so it would be useful to other people. I think that a generic JDE interface for Java extensions would have the following elements: - A Java API to encapsulate the Java-Emacs communications (with methods like move point, change selection, get region, etc.) This code would do the socket-based or gnuclient-based communication behind the scenes. - An installer tool that would generate the necessary elisp wrapper code from a Java interface. I think that using Java Reflection this would be an easy task, although another option would be to require the tool writer to provide an interface descriptor in a text or XML file - which could support annotations for the creation of menus and keybinds. The first component would be used by the most complex full-duplex tools, like refactoring libraries and UML browsers (for example, to allow changes in an UML GUI to be reflected in an Emacs buffer). The second could be used by both full-duplex and the most generic half-duplex tools, where elisp is used to call a Java library for a straightforward operation - like the JDE wizards, code checkers and beautifiers, etc. With these two components Java designers would have a much easier time extending JDEE - all the hard work, including writing the elisp wrappers and the communication code, would have already been done for them, and in an standard way. Regards, Nascif
RE: Interfacing Java tools with JDEE
Title: RE: Interfacing Java tools with JDEE Hi Paul, [snip] The jde-jeval function already provides all the functionality required for two-way communication between the JDEE and an external Java application. I explained how this works in a previous post. Paul, jde-jeval provides all the functionality required for two-way communication - assuming that: 1) the Java tool was written with Emacs interaction in mind, since in order to do Java-elisp actions the tool has to return proper elisp code for evaluation. 2) The flow control is completely under the control of the elisp side. These two assumptions are not always the case for many good tools out there. Nonetheless these tools are useful enough to make their integration to JDEE a worthwhile goal. Take a refactoring tool like Transmogrify as an example. First, it was designed as a plug-in for a generic Java editor, and Emacs-JDEE currently don't qualify as such. Case in point, Transmogrify don't return elisp code for evaluation to affect the environment. Second, once a refactoring is started (in the JDEE case, by a jde-eval call to the associated Java method) the tool takes control of the flow control, making calls back to the editor environment based on internal decisions. For example, it may query the contents of the region, and based on analysis of that content ask the editor to change point. This is a much more complex iteration model than the one supported by jde-jeval. The only thing that Nascif is proposing to add is a Java wrapper around Lisp code required for the Java application to manipulate Emacs. From the discussion above, you can see that this wrapper is much more than that. It allows JDEE to be extended with Java tools that know nothing about Emacs or Elisp, and is much more flexible in its assumptions of the flow control. I think the jde-jeval approach of having the Java process simply return Lisp code is superior because it allows the Java process to have access to the full range of Emacs functionality. True, but at a big price; to use this approach a Java tool has to be written (or re-written) to fit into the jde-jeval model. I won't argue that it is better for tools created from scratch to be integrated with Emacs by a Java/Lisp programmer; but I don't think it is sufficient to support already existing tools, nor tools created by designers that are not proficient in elisp. With Nascif's approach, only the functionality exposed by the wrapper code is available to the Java process. True, but then again, plug-ins typically are designed with access to a very small and well-defined API to the environment (the editor) in mind. With a dozen methods exposed (get/set region, get/set point, load buffer, etc.) we would be able to support a very broad range of Java plug-ins. We could always expose a Lisp pass-through, to allow the Java tool to send elisp code back. In this way the Java wrapper would be a superset of the jde-jeval approach. As for avoiding learning Lisp, I think people who want to write Java extensions to Emacs are better off putting their effort in learning elisp than in learning a Java wrapper around elisp. Paul, what about people that want to write a Java plug-in for *any* editor? In that sense JDEE/Emacs is too far away from the other IDEs out there. Not better or worse, but different. True, there is no standard for plug-ins at this point, but the ones already available (from NetBeans, JEdit, JBuilder, just to name a few) don't rely on elisp... Not to mention the plug-ins and tools that have already been written. Is it a good position to simply ignore them, or to have to rewrite them from scratch? I think JDEE would greatly benefit by providing a true Java-based plug-in architecture and removing the elisp language barrier. What is the problem of offering a more generic and easy to use way for Java designers to extend JDEE? Nothing against learning elisp, but code re-use and standardization are worthwhile design goals as well. They may take away some flexibility, but the payback is great - more people will be adding extensions because of the reduced barriers. Best Regards, Nascif
RE: Interfacing Java tools with JDEE
Title: RE: Interfacing Java tools with JDEE Hi Vasek, -Original Message- From: Vaclav Barta [mailto:[EMAIL PROTECTED]] Paul, what about people that want to write a Java plug-in for *any* editor? In that sense It's simple: they can't. Not all Java editors are written in Java OK, I was too generic. But you would agree that *most* of the Java editors in large use today 1) are Java-based 2) support extensions (plug-ins) written in Java. - you'll always have different languages standing in the way of re-use... For maximum pluggability, you can go below programming language level and communicate using structured data - Emacs supports that (note how pluggable javac and other compilers are), but of course it has its own problems... I want to solve a much more specific problem: Java plug-ins for JDEE. JDEE/Emacs is too far away from the other IDEs out there. Not better or worse, but different. It isn't just the case of Emacs - I wouldn't expect (for example) Microsoft tools to be scriptable in Java either... I'm not trying to solve that problem. [snip] I think JDEE would greatly benefit by providing a true Java-based plug-in architecture and removing the elisp language barrier. What is I disagree. IMHO it's Emacs which would greatly benefit from being scriptable in multiple languages - but I don't see that happening this century... :-) Maybe, but I'm not fighting this battle. Last time I posted about this issue I got a lot of replies talking about extending Emacs with Java, Perl, etc. This is not the point I'm making. I'm talking about a very specific feature (support for Java plug-ins) for a very specific Emacs package (JDEE). I think that by keeping the focus we can have it happenning much sooner than the end of the century... ;-) and easy to use way for Java designers to extend JDEE? Nothing against learning elisp, but code re-use and standardization are worthwhile Well, Emacs is standartized on elisp. I agree that most Java tools are standartized on something entirely different, but if someting has to give, I'd try to push the Java tools first - Emacs is just too heavy to push around... Emacs is flexible enough to support a middle ground solution. Regards, Nascif
ANN: JDE interface to Code Beautifier (Jalopy)
Title: ANN: JDE interface to Code Beautifier (Jalopy) Hi all, Attached you will find an Emacs/JDEE plug-in package for the Jalopy tool. From the Jalopy (http://jalopy.sourceforge.net/) web page: Jalopy is a source code formatter for the Sun Java programming language. It layouts any valid Java source code according to some widely configurable rules; to meet a certain coding style without putting a formatting burden on individual developers. With Jalopy you will be able to transform any foreign coding style to your own preferences, without any browbeating or bloodletting. Jalopy's functionality covers: Brace style transformation Fine-grained whitespace settings Indentation Intelligent line wrapping Code separation Javadoc auto-generation Header/Footer templates Paul, I don't have a permanent web page to store the file, so I would appreciate if you could add it to the Contributed software page. Enjoy, Nascif jde-jalopy.el Description: Binary data
ECB 1.80 vs JDE 2.2.9beta10: Semantic version conflict?
Title: ECB 1.80 vs JDE 2.2.9beta10: Semantic version conflict? Hi, I installed the latest ECB and required packages. One of the changes was to upgrade to the latest version of semantic, 1.4. I later found out that JDE wouldn't launch. JDE prints an error message claiming that it supports Semantic only up to the version 1.4beta14. I tried to force JDE by changing the version check, but then calls like jde-normalize-path started to fail. Regards, Nascif -Original Message- From: Jesper Nordenberg [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 4:13 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: ECB 1.80 ECB, Emacs Code Browser, version 1.80 is now available at: http://home.swipnet.se/mayhem/ecb.html This release contains many new features and some bug fixes. ECB now requires semantic 1.4 and EIEIO 0.17, no beta versions. ECB is a source code browser that displays directories, source files, methods and variables that can be navigated using the mouse (and keyboard). It supports parsing of Java, C, C++ and Elisp source code. It is completely written in Emacs Lisp and uses semantic to parse source files. Contributions, suggestions and bug reports are welcome! Please send them to the public mailing list: http://lists.sourceforge.net/lists/listinfo/ecb-list /Jesper Nordenberg
RE: Re[4]: missing features in jde?
Title: RE: Re[4]: missing features in jde? Hi there, The problem of usage information gathering is also a pre-requisite to the implementation of refactoring tools (and xref is actually an example of such a tool). So they provide a good place to look for examples on how to solve this problem (as long as you don't mind using Java instead of elisp for the parsing engine). Below you will find links to open source refactoring tools for Java . FreeFactor has already an Emacs interface. https://sourceforge.net/projects/freefactor/ https://sourceforge.net/projects/transmogrify/ http://jrefactory.sourceforge.net/csr-commandline.html Good luck, Nascif -Original Message- From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]] Sent: Friday, October 25, 2002 2:30 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re[4]: missing features in jde? Semanticdb for the next release is much more advanced than the current one. It will come with a command line program to build a complete set of databases you can reference. It still won't help with usage information though. Eric Andrew Hyatt [EMAIL PROTECTED] seems to think that: So far I haven't found a way to get the information I need by Semantic only. I think actually it is theoretically impossible, unless we also require semanticdb's to be made for each file. We could do it with a combination of Semantic and bsh, but that sort of thing has been slow for me in the past (when we use completion, for instance), so I'm not too confident about it. I think a better way to do it is to parse the class file itself. The Java compiler has already done the heavy lifting here, it has the exact fully-qualified functions that are called, we just need to go and parse out the relevant information. I think this could be very fast. Also, this allows us to retrieve usage information for anything that compiles to Java bytecode, and gives us access to classes we don't have the source code to. The disadvantage if we don't get line numbers if the class file has no debug info, but we could get the class and function name each call is in. I think that's good enough. I'm working on the class-file based approach right now, and am building a simple parser for it (I don't think semantic can handle binary files, but correct me if I'm wrong). Whether I do a full parser of just a quick parse of the stuff we need I haven't decided yet. Eric M. Ludlam [EMAIL PROTECTED] writes: It might be possible to do such a thing with semantic 1.4, though it would be very slow. The new bison based parser David Ponce ported into the semantic 2.0 CVS also has a full java parser. I'm not exactly sure what it's capabilities are though. As far as I know, the CVS version is still compatible with the current version of JDE. Eric Andrew Hyatt [EMAIL PROTECTED] seems to think that: You can actually get the find usages functionality with the xref program, a program not only amazing for this feature, but also the fact that it is an emacs extension that costs money! See it at: http://xref-tech.com/xrefactory/ It costs $29. I bought it and use it, and it's good, but I think a better solution could probably be designed for free. I'd actually like to work on this functionality for jde, if it was possible to do. I don't know enough about semantic to tell whether it is powerful enough to support this functionality (all we would need is to tag lines by what functions of what classes are called, then create and store a big table of these), but I think so. We can take it a step farther than xref by adding functionality to produce call trees, which would be incredibly useful. Even though it appears possible, I remember reading on this list that it would require semantic 2.0 to do? If anyone has any further information on that, I'd be interested to hear. Paul Kinnucan [EMAIL PROTECTED] writes: Raul Acevedo writes: I've been using JDE for a while, and while I'm generally happy with it, there is some basic functionality that it seems to be missing: * Minibuffer completion on class names for jde-open-class-source. * Find usages functionality: list all callers/users for a given method, field or class. No, I don't want to use grep, I want something 100% reliable. * Functionality to list all classes/interfaces which implement/extend a given class/interface. JDE is great, but these features are pretty standard on most Java IDEs and they are quite useful. Are they there and I've missed them, or will they be provided in a future release? Hi Raul, Thanks for the suggestions. Others have requested some of these features as well. I think they'd be interesting to implement. I
accumulative changes in prj.el files
Title: accumulative changes in prj.el files Hi, I would like to setup my prj.el files so that I can have the subproject prj.el files adding to basic values defined on the master prj.el, or on my .emacs. For example, I would like to have a basic lists of classes defined for the jde-global-classpath and jde-sourcepath lists, and have prj.el on subprojects adding classes to those lists - not completely redefining them. I guess I could do that writing elisp code in my prj.el file, but I remember reading somewhere that you are not supposed to direct set the values of defcustom variables. So I would like to keep using the custom package to manipulate those variables if at all possible. I would appreciate any help. Regards, Nascif
RE: prj.el under source control
Title: Message Hi Guillaume, That is a very good hint, I'll keep an eye for that. Thanks, Nascif -Original Message-From: Guillaume Berche [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 3:14 AMTo: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; [EMAIL PROTECTED]Subject: RE: prj.el under source control Nascif , I've had similar problems using CVS on a previous JDEE version. The problem was I added the prj.el files as a text file whereas under certain conditions it might contain binary characters (such as when specfying a control key in the key bindings) that CVS considered as end-of-file marker, and thus truncated the file. After modifying the file attribute to binary, this worked again. I hope this can help, Guillaume. -Original Message-From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]Sent: mardi 19 novembre 2002 22:29To: [EMAIL PROTECTED]Subject: prj.el under source control Hi, I recently added our prj.el files to source control (clearcase) but soon after that I start to get some strange behavior - basically related to loss of customizations, like modeline, font-lock, key bindings, and project name. I'm not sure it is related, but I'm thinking that the fact that fact that the prj.el is now read-only may be causing problems. Could that be the case? Another variable: I recently migrated from jde2.2.9beta10 to jde2.2.9. I tried to move back but the problem persisted. Regards, Nascif PS: Still no comments on my previous question on how to have subprojects appending to paths defined on parent projects, instead of just overriding then...
RE: jde-jalopy.el
Title: RE: jde-jalopy.el http://home.nc.rr.com/nascifandelaine/emacs.html Enjoy, Nascif -Original Message- From: Keith Kee [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 12:20 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: jde-jalopy.el Hi: Where do I pick up the latest jde-jalopy.el? Thanks keith
RE: JDEE plugins (was JUCI)
Hi James, Thanks for your e-mail, and agreed in all points. I didn't realize that there is a JSR going on for plug-ins, it is really a good idea to take a look at it and try to conform. Once I thought about peeking one of the more mature plug-in APIs like OpenTools for JBuilder and try to emulate, so that we could re-use their already made plug-ins. But that are problems with that - you're now tied to a commercial API - so a JSR-compliant API makes much more sense. As for your questions: 1) I would say people and technology are the major problems (we don't have a deadline). From my little experience in this area, anything other than very trivial plug-ins (basically launching a Java app to process the current buffer and capture the results) requires a fair amount of elisp knowledge. And as far as technology, as we discussed before in this list, it is quite hard to get the Java code to drive the control flow (allowing it to change the contents of the buffer, change the cursor position, open new windows, etc.). It can be done but it depends on interprocess communications, which adds a lot of complexity. I used gnuclient for that purposes, Paul used direct socket communication in the JDEbug. The JUCI package will I believe address this problem in a generic way. 2) I think extending JDE is the way to go. Note that it is quite easy, today, to integrate Emacs in many IDEs by using gnuclient. 3) As I said above, this looks like a great idea. It may be the case that we won't be able for performance or other reasons to have a 100% Pure Java plug-in API; but if we can, by all means it should follow a standard. Regards, Nascif -Original Message- From: James Higginbotham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:21 PM To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: JDEE plugins (was JUCI)
Well, looks like I jumped the gun. There is not API to look at yet for this JSR 198. I suggest we just move ahead (who know long it will take to get to a point where actual APIs are defined, this looks like a very hot politic issue as well http://news.com.com/2100-1001-978445.html) and later consider a move to conform to whatever they define. In the mean time we will learn a lot :-) -Original Message- From: James Higginbotham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:21 PM To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: JDEE plugins (was JUCI)
Hi Nick,
Where possible, talk in terms of emacs
interface objects (buffers, windows, frames, region, point,
etc.) but also express them in terms of what a Java interface
might look like. What are the logical groupings for
retrieving certain kinds of information? What would you name
an interface for fetching the current buffer, the current
buffer file, the current class, etc.?
I attached the module that implements the generic Java-Emacs interface in
the jde-transmogrify package. It was done to mirror the Transmogrify Hook
interface, which I believe was derived from the JBuilder plug-in interface.
We could use it as a starting point, as it is part of a working plug-in
(in the sense of a Java-based add-on to JDEE).
The relevant methods (that Java code can use to change the Emacs
environment) are:
42: public void showReferencesSourced(IDefinition definition) {
57: public void showReferencesNonsourced(IDefinition definition) {
67: public void openFile(String sourceFileName)
78: public File[] getFiles()
90: public String getCurrentFile()
102: public String getUserInput(String prompt, String title)
108: public void displayMessage(String title, String message)
113: public void displayException(Exception e, String description) {
135: public String getText()
146: public String getLine(int lineNumber)
159: public void selectText(int startLineNumber,
177: public void selectText(int startPos, int endPos)
188: public void deSelectText()
198: public String getSelectedText()
208: public Enumeration getSelectedLines()
219: public int getCaretLineNumber()
230: public int getCaretOffset()
242: public int getCaretPos()
248: public int getSelectionStart()
254: public int getSelectionEnd()
266: public void setCaretPos(int lineNumber, int offset)
279: public void setCaretPos(int pos)
Regards,
Nascif
EmacsHook.java
Description: Binary data
[ANN] PMD interface for Emacs
Hi all, Take a look at PMD (http://pmd.sourceforge.net/ http://pmd.sourceforge.net/ ). This is a Java source code analyser similar in some aspects to CheckStyle, but with some very interesting non-overlapping features: Unused local variables Unused parameters Empty 'if' statements Unused private methods Classes which could be Singletons Classes with high Cyclomatic Complexity numbers Classes with high coupling/high external dependencies (OK, so CheckStyle may also support some of those, not really sure). PMD is also very extensible so you can create your own code checking rules. The emacs interface package is (so far) *not* JDEE-aware. Regards, Nascif
RE: [ANN] PMD interface for Emacs
I saw your version, Jason. The current version is very similar (user the compilation mode as well). Take a look at the new command, pmd-current-dir. You may want to call it every now and then instead of calling pmd-current-buffer for every file every time you save them (although I agree, the JVM delay is not that bad). Actually there is quite a lot of commonality between this module, and jde-checkstyle, and jde-jalopy, etc. Calling a Java app that redirects its output to a compilation buffer seems to be a common pattern. It would be good to refactor the common code into JDE. I'm planning to release a more efficient version (using bsh, maybe jde-sourcepath) as soon as the next JDEE version is out with the first version of the plug-in capability. Regards, Nascif -Original Message- From: Jason Rumney [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 5:01 PM To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH] Cc: [EMAIL PROTECTED] Subject: Re: [ANN] PMD interface for Emacs Nascif Abousalh-Neto [EMAIL PROTECTED] writes: The emacs interface package is (so far) *not* JDEE-aware. I've been meaning to do something with it for a few weeks now. I sent in some patches a month or so ago to make it use compile-mode, so at least you could click on the lines, without realizing there was an improved version in CVS already (so now there are two interfaces to choose from). But I also planned to modify it to use bsh if available rather than spawning a new JVM every time. I run pmd as part of my write-file-hooks, and even spawning a new JVM every time it has not been sufficiently slow to annoy me yet.
FYI: CheckStyle v3.0 available
Hi, Looks like there is a new version of CheckStyle out there, with some really cool enhacements (I particular I like this one: Detect hiding of fields by parameters or local variables with the same name). The bad news is: As of release 3.0 Checkstyle has changed it's configuration system. The configuration file is now an XML file that configures a tree of check modules. The Checkstyle 2 configuration files (based on properties) are not supported in Checkstyle 3. Please consult the documentation to learn about the new configuration file format. http://checkstyle.sourceforge.net/releasenotes.html Regards, Nascif
RE: [ANNOUNCEMENT] JDEE 2.3.3beta2
Does this version adds support for the new plug-in framework? I found no mention of it in the release notes. Regards, /Nascif
RE: Refactoring with JDE?
Hi Andrew, -Original Message- From: Andrew Hyatt [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 5:00 PM To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH] Cc: [EMAIL PROTECTED] Subject: Re: Refactoring with JDE? Nascif Abousalh-Neto [EMAIL PROTECTED] writes: Hi Andrew, Hmm, I have to disagree here. First I don't think you can beat a refactoring editor in terms of speed if you take into account propagating the changes to all affected modules, specially in a medium-large project (think rename method, or even rename variable for a protected variable used by many subclasses). Since emacs is all about speed, it makes sense to use a specialized tool rather than macros and other tricks if one is available. For things that need to know caller locations, true. But jde-xref already handles that info, it could be extended to some of those refactorings. But many of the common Good point. What do you think should be the way to go with support for refactorings in JDE? I can see three major directions: 1) Expanding on the jde-xref functionality 2) Using the new semantic 2.0 - assuming it has all the necessary functionality 3) Use a Java-based backend or C-based, like Transmogrify or xrefactory. I think that using an approach similar to the JDE compile server, which keeps an instance of the java compiler running at all times, the Java approach may be feasible in terms of performance. Then again I don't know how Lisp-based grammars compare in terms of speed and memory usage with Java-based ones. refactorings such as extract method, pull up method, etc, are easy to do by hand. For the extract method refactoring, consider a block of code that uses local variables. You have to create for each instance of a local variable an equivalent method parameter, and fill the method call with the associated arguments. And so on. A true refactoring tool is very much like a calculator; sure you can make basic calculations by hand and most of the time it is faster this way, but besides the trivial cases you always use the calculator not only for speed, but also so that you don't worry if any of the intermediate steps in your 5-digit multiplication was wrong and can trust the result - OK, maybe I am bad in math... :-) The problem with the more advanced IDE's is that they are SLOW. Eclipse is supposed to me much faster then JBuilder, and Eclipse is just a dog compared to emacs. Eclipse makes doing advanced things easy, and by doing this they slow down normal editing. Personally, I prefer a fast editor above all else. (Yes, I know you can turn off certain features in Eclipse to speed things up, but this eliminates many of the good features of Eclipse). Perhaps there is a way for us to have our cake and eat it too. But I for one haven't thought of how. Agreed. I also choose speed over bells and whistles hands down. But given Emacs power I think it may be possible to have both; it may be more a matter of finding the right balance between speed and functionality. Regards, /Nascif I have been thinking about it as well. I agree it would require a lot of JDE changes to make things more consistent, but is that necessarily a bad thing? I don't see why JDE would lose flexibility, and actually I think it would have two benefits: 1) It could make JDE more efficient by doing a very core thing - keeping the structure of the code in a usable format - in exactly one place. Granted it is a complex and expensive operatation, which is exactly why it should be done once and re-used by all other modules. 2) It would allow for more powerful extensions/plug-ins because the hard work of gathering semantic info from the code would already have been done; designers would only have to learn the API to get them; 3) Not only refactorings could be done but all kinds of operations can benefit from a better model of the code. For example, the try-catch replacement we have talked about in this list could wrap the code using the exact exceptions; searches could filter on exact characteristics (like search method call); and so on. It's not the flexibility of JDE I am concerned about, it's the flexibility of users. It somehow feels wrong if JDE would require a lock-in in the same way Eclipse (and probably other JDE's do). I agree with you to an extent about the usefulness of centralizing semantic info, but I'm not sure it should be done ahead of time. If it could be done as needed it might be better. Regards, /Nascif
RE: jde-jalopy update
Hi Paul, I will merge your changes and roll out a 1.4 version soon (but not too soon, I am a little swamped right now). If time permits I will also roll out the Jalopy jar file into a .zip and make that a true JDEE plug-in. Thanks for the new features! Regards, Nascif -Original Message- From: Paul Landes [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 1:56 PM To: Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: ANN: jde-jalopy update I knew I should have gotten this done sooner. I did some hacking on this because I couldn't get Bob's code to work (at least under XEmacs). Since the thing is in such a flux, I'm just going to attach what I have. I started with what was on your site, Nascif. Nascif Abousalh-Neto writes: Hi all, I uploaded version 1.3 of jde-jalopy.el, which incorporates the method jde-jalopy-buffer posted by Bob Schellink. Enjoy, Nascif http://home.nc.rr.com/nascifandelaine/emacs.html ;;; jde-jalopy.el --- JALOPY interface for JDE ;; Copyright (C) 2002 Nascif A. Abousalh Neto ;; Author: Nascif A. Abousalh Neto nascif at acm dot org ;; Maintainer: Nascif A. Abousalh Neto [EMAIL PROTECTED] ;; Keywords: java, beautifier, pretty printer, tools ;; Time-stamp: 2002-12-04 00:48:50 nascif ;; ;; Version: 1.2 ;; ;; 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 1, 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. ;; A copy of the GNU General Public License can be obtained from the Free ;; Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ;;; Commentary: ;; This package provides an interface from JDE (see http://jde.sunsite.dk/) to ;; Jalopy (see http://jalopy.sourceforge.net/). Jalopy is a `a source code ;; formatter for the Sun Java programming language. It layouts any valid Java ;; source code according to some widely configurable rules; to meet a certain ;; coding style without putting a formatting burden on individual developers.' ;; Installation: ;; ;; 1) Download and install the Jalopy console plug-in package from: ;; http://jalopy.sourceforge.net/download.html ;; ;; 2) Put this file on your Emacs-Lisp load path and add the following into ;; your .emacs startup file ;; ;; (require 'jde-jalopy) ;; ;; 3) Customize the variable `jde-jalopy-option-path' to point to the Jalopy ;; installation directory. ;; ;; 4) Make sure JDE is properly configured. In particular set the variables ;; jde-jdk-registry and jde-jdk so that the JVM launcher can be found. ;;; Usage: ;; ;; M-x `jde-jalopy-file' to reformat the Java source file associated to the ;; current buffer. ;; ;;; Customization: ;; ;; To customize the Jalopy-Emacs interface options, use the command: ;; M-x `jde-jalopy-customize' ;; ;; The default behavior for Jalopy is to format the code according to the Sun ;; Code conventions. If you want to customize the formatting behavior (and ;; Jalopy supports a large number of customization options), use the command: ;; M-x `jde-jalopy-preferences' ;; ;; This command will launch the Jalopy Preferences editor GUI-based tool. You ;; can use it to create a file with your customized preferences. Point the ;; variable `jde-jalopy-option-preferences-file' to this file. I suggest you ;; save the file in the XML format, so that you can edit the preferences file ;; directly in an Emacs buffer later. ;;; Acknowledgements: ;; ;; This code is heavily based on jde-check.el, by Markus Mohnen. ;;; ChangeLog: ;; 1.3 - added jde-jalopy-buffer, which jalopifies a buffer in place ;; ;; 1.2 - jde-jalopy-buffer renamed to jde-jalopy-file to clarify its behavior. ;; ;; 1.1 - updates to support Jalopy 1.0b10 (changes in location of jar files) ;; ;; 1.0 - first version, supporting Jalopy 1.0b8 ;;; Code: (require 'jde-compile) (if (fboundp 'jde-build-classpath) nil (require 'jde-run) (defalias 'jde-build-classpath 'jde-run-build-classpath-arg) ) (defconst jde-jalopy-version 1.0b10) (defgroup jde-jalopy nil JDE Jalopy Options :group 'jde :prefix jde-jalopy-option-) (defcustom jde-jalopy-option-class de.hunsicker.jalopy.plugin.console.ConsolePlugin *Jalopy console plug-in class. Specifies the Jalopy console plug-in class. There is typically no need to change this variable. :group 'jde-jalopy :type 'string) (defcustom jde-jalopy-option-preferences-class de.hunsicker.jalopy.swing.SettingsDialog *Jalopy console plug-in class. Specifies the Jalopy console plug-in class. There is typically no need to change this variable. :group 'jde-jalopy
RE: jde-flymake
http://www-124.ibm.com/developerworks/opensource/jikes/ -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: Sat 3/13/2004 2:36 PM To: Nascif Abousalh-Neto; [EMAIL PROTECTED] Cc: Subject: RE: jde-flymake Where to get jikes? -Original Message- From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 6:51 AM To: [EMAIL PROTECTED] Subject: ANN: jde-flymake Hi all, I also posted an initial version of jde-flymake, which provides extensions to Flymake (http://flymake.sourceforge.net/), an on-the-fly syntax checker for Emacs created by Pavel Kobiakov. Flymake comes with built-in support for Java but relies on Makefiles for calling Jikes; this module relies instead on JDEE project variables, removing the need to create Makefiles just for the purpose of using Flymake. NOTE: jde-flymake.el requires a patched version of flymake.el. The patch have been submitted to the author. In the mean time you can get a patched version on my download page. Regards, Nascif http://home.nc.rr.com/nascifandelaine/emacs.html
ANN: jde-flymake update
Hi all, I incorporated enhancements from Christopher (thanks!) and tested (in Emacs only, there may be some problems with Xemacs) with the latest version of flymake in CVS, which incorporates the patches necessary to use with jde-flymake. I also created a new module with a helper function that makes flymake more convenient to use with the keyboard. Get the new version at: http://home.nc.rr.com/nascifandelaine/emacs.html Enjoy, Nascif PS: I had many jde-jalopy extensions sent to me recently, but I am still working on the merging. Thanks to all that sent extensions and sorry for the delay.
RE: JDE 2.3.4beta3: strange overlining
Hi Petter, This is a behavior in the Senator package that seems to be enabled by default in the new CEDET. On the Emacs menu, select Senator and then Modes. You will see that *all* of them are enabled. Disable Show Tag Boundaries and Highlight Tags by Attribute. I disabled everything actually. Regards, Nascif -Original Message- From: Petter Måhlén [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 7:16 AM To: [EMAIL PROTECTED] Subject: 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
W3m binary for windows
Hi there, I have been reading about w3m + Emacs and that some lucky guys out there are already browsing their Javadoc pages with it inside Emacs. How cool is that? :-) I would like to do the same as well, but I am having a hard time collecting all the pieces to build w3m on my WindowsXP + Cygwin box. I found some really old (1999) Windows binaries which don't seem to work. Does anybody has a more recent version available? And isn't this package useful enough to be included with the default JDE distribution - or at least to have a pointer to it in the JDEE documentation? Regards, Nascif
RE: W3m binary for windows
I did, but they are 4-5 years old. I was able to compile the latest w3m (had to install and compile a garbage collection package first, and change my configuration so that the gc.h include file could be found by gcc). Emacs-w3c works fine, a really nice extension to JDEE. One less reason to leave Emacs :-) Regards, Nascif -Original Message- From: Suraj Acharya [mailto:[EMAIL PROTECTED] Sent: Monday, April 26, 2004 1:23 PM To: Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: Re: W3m binary for windows Take a look at http://www.w3m.org/. It has cygwin binaries for windows. Suraj On Mon, 26 Apr 2004 10:29:40 -0400, Nascif Abousalh-Neto [EMAIL PROTECTED] wrote: Hi there, I have been reading about w3m + Emacs and that some lucky guys out there are already browsing their Javadoc pages with it inside Emacs. How cool is that? :-) I would like to do the same as well, but I am having a hard time collecting all the pieces to build w3m on my WindowsXP + Cygwin box. I found some really old (1999) Windows binaries which don't seem to work. Does anybody has a more recent version available? And isn't this package useful enough to be included with the default JDE distribution - or at least to have a pointer to it in the JDEE documentation? Regards, Nascif
jde-import-sort
When I try to use the JDE wizards to create a new class, the code generation fails (creates only part of the class) and I get the following error message: jde-import-sort: Semantic Java parser not found. JDE 2.1.6-beta24+ needed. I looked around and it seems that the problem is with the call to jde-import-sort, which relies on a deprecated variable in sematic: From jde-import.el: (or (and (local-variable-p 'semantic-toplevel-bovine-table (current-buffer)) (symbol-value 'semantic-toplevel-bovine-table)) From semantic.el (latest from new CEDET package:) (defvar semantic--parse-table nil Variable that defines how to parse top level items in a buffer. This variable is for internal use only, and its content depends on the external parser used.) (make-variable-buffer-local 'semantic--parse-table) (semantic-varalias-obsolete 'semantic-toplevel-bovine-table 'semantic--parse-table) Regards, Nascif -- Nascif A. Abousalh-Neto Inventory Replenishment Planning Java Architect SAS Institute, Inc. 100 SAS Campus Dr, R4113 Cary NC 27513-8617 Tel 919-531-10123
Problems with ResourceBundle
Hi, I am developing an internationalized GUI. When I launch my application from the shell prompt using a script wrapper, it can find the resource bundle, no problem. When I run it from JDEE using the jde-run command, I get : java.util.MissingResourceException: Can't find bundle for base name com.sas.analytics.irp.client.resources, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:804) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:773) at java.util.ResourceBundle.getBundle(ResourceBundle.java:661) at com.sas.analytics.irp.client.util.ResourceProvider.init(ResourceProvider.java:41) I checked the classpath and it is exactly the same, and the resource bundle file is right there where I expect it (inside the main jar file). Any idea what could be the difference between launching from a script and launching from JDEE that would explain this difference in behavior? TIA, Nascif
RE: Real time syntax checking ?
Also note that Flymake can be used to validate XML files on the fly, even ones without a formal DTD. *Very* convenient when playing with Ant build.xml files. To enable XML validation, you will need the XMLStar tool from this site: http://xmlstar.sourceforge.net/ Regards, Nascif -Original Message- From: Suraj Acharya [mailto:[EMAIL PROTECTED] Sent: Sunday, May 30, 2004 3:32 AM To: Ding Lei Cc: JDE Mailing List Subject: Re: Real time syntax checking ? The closest you can get is jde-flymake (http://home.nc.rr.com/nascifandelaine/emacs.html) which runs jikes frequently and parses its error and warning messages. On a fast machine this works surprisingly well. Suraj On Sun, 30 May 2004 12:55:50 +0800, Ding Lei [EMAIL PROTECTED] wrote: Hi, Is JDEE possible to do real time syntax checking while coding ? I first found this feature in Eclipse, it really saves lots of time. Anyway ... even If the answer is NO, i will be still be using emacs/jde, really love it so much :) Thanks. -- : D i n gL e i :: || || || Ext: 8106|| || Email: dinglei [A] ipanel [O] cn || || Dept. Of Technology/Engineering || || Embedded Information Services Inc. || || || ((= ) After a number of decimal places, nobody gives a damn.
RE: flymake / jde-flymake problem
Hi Milan, I searched for this error message in both flymake.el and jde-flymake.el and I was not able to find it. I wonder if it was not a problem during configuration, given that it is quite complex. In order to narrow down the possibilities, I would suggest the following: 1) enable debug-on-error to get a full trace; 2) make sure you are using the correct version of flymake - not the official one (0.2) but the one from CVS: http://cvs.sourceforge.net/viewcvs.py/flymake/flymake/ 3) double check the customization With the stack trace of the error it should be easier to find out what is happening. I use jde-flymake on a daily basis. My environment is Windows NT with GNU Emacs 21.1. What is yours? It could be also an environment problem, Windows vs. *nix or Emacs vs. XEmacs. Regards, Nascif -Original Message- From: Milan Zimmermann [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 1:30 AM To: [EMAIL PROTECTED] Subject: flymake / jde-flymake problem Hello, I am wondering if anyone using flymake and jde-flymake here. I installed both following the instaructions in jde-flymake customized variables etc, but when I try to M-x flymake-mode on java file (e.g. MyClass.java) I get a message: Opening directoty: Not a directory, path-to-my-class/MyClass.java I am getting the same message trying to use other flymake commands (such as flymake-start-syntax-check-for-current-buffer. Anyone has an idea what could be wrong? Thanks Milan
ANN: pmd-emacs
Hi all,
Just posted a new version of the Emacs plug-in for PMD (get it from SourceForge, see
links below).
PMD is a syntatic code analyser similar to CheckStyle - but with a focus more towards
potential problems (e.g. unused variables) then syntatic guideline violations. It is
also quite easy to customize with new rules.
It can be used as lint, providing rule violations in a compile buffer and allowing
you to jump directly to the associated source code line.
Happy Hacking,
Nascif
-Original Message-
From: SourceForge.net [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 10:09 AM
To: [EMAIL PROTECTED]
Subject: [SourceForge.net Release] pmd : pmd-emacs
Project: PMD (pmd)
Package: pmd-emacs
Date : 2004-06-17 09:09
Project PMD ('pmd') has released the new version of package 'pmd-emacs'. You can
download it from SourceForge.net by following this link:
https://sourceforge.net/project/showfiles.php?group_id=56262release_id=246573
or browse Release Notes and ChangeLog by visiting this link:
https://sourceforge.net/project/shownotes.php?release_id=246573
You receive this email because you requested to be notified when new versions of this
package were released. If you don't wish to be notified in the future, please login to
SourceForge.net and click this link:
https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=53584
If you lost your SourceForge.net login name or password, refer to this document:
https://sourceforge.net/docman/display_doc.php?docid=760group_id=1
Note that you may receive this message indirectly via one of your mailing list
subscriptions. Please review message headers before reporting unsolicited mailings.
RE: flymake / jde-flymake problem
Thanks Milan! Glad to see it is working for you now. I just updated the latest version to my web site, Plus a link to the PMD plugin in SourceForge. Regards, Nascif -Original Message- From: Milan Zimmermann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 10:37 PM To: Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: Re: flymake / jde-flymake problem Nascif, The modified version works just beautifully! ECB+JDE+jde-flymake .. great environment, thanks! (I have been using JDE a long time ago but recently only IDEA at work and Eclipse at home, but Eclipse, at least on Linux, is so slow now that it became unbearable. I am gonna try your PMD plugin in the next few days as well, but still have lots to learn on JDE setup + project building.) Thanks again, Milan On June 17, 2004 02:44 pm, Nascif Abousalh-Neto wrote: Hey Milan, I think I got a bug - something that shouldn't be working but probably did because of my environment. Give it a try and see if this version works for you. /Nascif -Original Message- From: Milan Zimmermann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 1:57 AM To: Nascif Abousalh-Neto; [EMAIL PROTECTED] Subject: Re: flymake / jde-flymake problem Nascif, Thanks for your detail answer. This is on is Linux SuSE 8.1 Emacs v. 21.2.1 ... I enabled debug-on-error, please see results and comments on you notes inline: On June 16, 2004 10:23 pm, Nascif Abousalh-Neto wrote: Hi Milan, I searched for this error message in both flymake.el and jde-flymake.el and I was not able to find it. i have looked in the message window and this the message seems from jde .. which seems weird as i never saw it in any other situation except trying any flymake command (even mode): # On flymake-mode, i get: Debugger entered--Lisp error: (file-error Opening directory not a directory /home/mzimmermann/projects/eclipse3workspace/airliftj/src/airliftj/uti l/en tityModelUMLToXML/UMLEntities2Hibernate.java) directory-files(/home/mzimmermann/projects/eclipse3workspace/airliftj/src/ airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java) jde-find-project-file(/home/mzimmermann/projects/eclipse3workspace/airlift j/src/airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java) flymake-jde-jikes-java-init(#buffer UMLEntities2Hibernate.java) flymake-start-syntax-check(#buffer UMLEntities2Hibernate.java) flymake-start-syntax-check-for-current-buffer() flymake-mode-on() flymake-mode() * call-interactively(flymake-mode) execute-extended-command(nil) call-interactively(execute-extended-command) In Message window: Loading /home/mzimmermann/projects/eclipse3workspace/airliftj/prj.el (source)...done [2 times] jde-find-project-file: Opening directory: not a directory, /home/mzimmermann/projects/eclipse3workspace/airliftj/src/airliftj/util /ent ityModelUMLToXML/UMLEntities2Hibernate.java # On flymake-start-syntax-check-for-current-buffer i get: Debugger entered--Lisp error: (file-error Opening directory not a directory /home/mzimmermann/projects/eclipse3workspace/airliftj/src/airliftj/uti l/en tityModelUMLToXML/UMLEntities2Hibernate.java) directory-files(/home/mzimmermann/projects/eclipse3workspace/airliftj/src/ airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java) jde-find-project-file(/home/mzimmermann/projects/eclipse3workspace/airlift j/src/airliftj/util/entityModelUMLToXML/UMLEntities2Hibernate.java) flymake-jde-jikes-java-init(#buffer UMLEntities2Hibernate.java) flymake-start-syntax-check(#buffer UMLEntities2Hibernate.java) flymake-start-syntax-check-for-current-buffer() * call-interactively(flymake-start-syntax-check-for-current-buffer) execute-extended-command(nil) call-interactively(execute-extended-command) recursive-edit() byte-code( ! !\n? I wonder if it was not a problem during configuration, given that it is quite complex. In order to narrow down the possibilities, I would suggest the following: 1) enable debug-on-error to get a full trace; ok thanks 2) make sure you are using the correct version of flymake - not the official one (0.2) but the one from CVS: http://cvs.sourceforge.net/viewcvs.py/flymake/flymake/ yes, i use the CVS version ... 3) double check the customization i believe i have items 1-5 correct (did not do the highlighting customization) there is only one variable to customize, is that correct? I am attacthing my prj.el - not that I would want you to spend time debugging my setup but just in case ... Thanks again, Milan
Jde-ant-enable-find
Is this variable (Jde-ant-enable-find) preserved between project switches? I always get the value set int the first project I load, even after switching to a second project where it is set to a different value. /Nascif
RE: maven contribution
That would be a nice extension to JDE. Would it be possible to extend the Ant Server or the Compile Server to make them generic enough to run Maven, or other Java-based tools like PMD, CheckStyle, etc., etc? I found that the code in AntServer.java and CompileServer.java is very similar; the differences could be refactored to a separate file, and a generic interface be defined. New Java-based plugins could implement this interface and thus be added to the JDE server support (through the BeanShell), instead of calling new JVMs on demand. Regards, Nascif -Original Message- From: Dominik Dahlem [mailto:[EMAIL PROTECTED] Sent: Friday, September 24, 2004 7:15 AM To: [EMAIL PROTECTED] Subject: maven contribution Hi all, I'm curious to know whether there are plans to add jde-maven.el under the hood of JDEE? There are two versions of jde-maven.el around [1,2] but they have not been contributed to the JDE CVS. Thanks, Dominik [1]-http://lists.gnu.org/archive/html/gnu-emacs-sources/2004-0 5/msg00032.html [2]-http://www.mail-archive.com/[EMAIL PROTECTED]/msg06674.html -- Dominik Dahlem [EMAIL PROTECTED] --- Trinity College Dublin Department of Computer Science, Dublin 2, Ireland tel: (+353) 1-608 1539 fax: (+353) 1-677 2204 www: http://www.cs.tcd.ie/Dominik.Dahlem/ ---
RE: refactoring in jdee
Another tool to consider is FreeFactor. It is in SourceForge, and it is already integrated with Emacs. It is still alpha, but is a good start for a true refactoring tool. http://sourceforge.net/projects/freefactor. A true refactoring tool needs access to the full syntactic tree of the source code - not just method signatures, but also method bodies. Does semantic support that? How about jde-usages?
RE: refactoring in jdee
I think this might be a problem for refactoring support, as you have to manipulate the source code on the abstract syntax tree level - a refactoring is usually implemented by applying a transformation to the AST, then generating code from the transformed tree or affected tree section (for all the files affected). Since you have to correlate the source code with the AST, I don't think that the byte-code would have enough information (maybe it has with the line numbers from the debug information, not sure). Maybe for some simple refactorings it would be sufficient, but for example for extract method, the input to the refactoring is a region in the source code - not a symbol name, but a sequencial group of lines. One would have to be able to map that back to the structure created from the byte-code. The documentation of CEDET (http://cedet.sourceforge.net/semantic.shtml) describes the following among the new features of the Semantic 2.0 package: Bison ported to Emacs David Ponce has ported Bison to Emacs Lisp. Languages supported via the new wisent parser will run faster. New languages will be easier to support as you can run a handy script to port directly from .y sources. Maybe the new parser could provide the more advanced data structures required to support refactoring. -Original Message- From: Suraj Acharya [mailto:[EMAIL PROTECTED] Sent: Friday, October 01, 2004 1:10 PM To: Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: Re: refactoring in jdee jde-usages doesn't parse any source at all, it only looks at byte-code from classes in jde-global-classpath. Suraj On Fri, 1 Oct 2004 12:36:57 -0400, Nascif Abousalh-Neto [EMAIL PROTECTED] wrote: Another tool to consider is FreeFactor. It is in SourceForge, and it is already integrated with Emacs. It is still alpha, but is a good start for a true refactoring tool. http://sourceforge.net/projects/freefactor. A true refactoring tool needs access to the full syntactic tree of the source code - not just method signatures, but also method bodies. Does semantic support that? How about jde-usages?
RE: Feedback needed on w3m support
I had this same problem; we solved it by configuring JDEE to create the temporary pages in a directory relative to the user's home, something like ~/tmp, instead of the default /tmp. Regards, Nascif -Original Message- From: Heinz-Dieter Conradi [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 3:17 AM To: [EMAIL PROTECTED] Subject: Re: Feedback needed on w3m support hi, without knowing anything about the problems involved, i would like to point out a potential problem with local files which has bitten me in the past: the local files are usually not writeable for other users. this is a problem when more than one person is working on the same workstation. although i like the frame display too, i would probably go for using non-local files without frames, heinz-dieter conradi
JDEE Wiki?
Hi Paul, Have you considered hosting a Wiki for the JDEE? I think it would cut a lot on basic questions, as it would be a more friendly way for JDEE users to share and organize their knowledge, tips, etc. It would definetely be more effective than browsing the mailing list. A Wiki with attachments capabilities (like JSPWiki) would also make it easier for users to post their own patches, plugins, etc. Regards, Nascif -Original Message- From: Jeff Greif [mailto:[EMAIL PROTECTED] Sent: Sunday, October 17, 2004 2:03 PM To: Anakreon; [EMAIL PROTECTED] Subject: Re: Syntax highlighting problem See http://www.mail-archive.com/[EMAIL PROTECTED]/msg07761.html and the other messages of that thread. Jeff - Original Message - From: Anakreon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 17, 2004 10:43 AM Subject: Syntax highlighting problem Version info emacs:GNU Emacs 21.3.1 jde:the latest stable release OS:Linux The problem is that after the firts java file is loaded, any other java file I load is displayed without syntax highlighting. If the jde is not loaded at startup, then this behaveur does not apear. Anakreon.
RE: Investigating quickfix functionality
Hi Kai, Great job! Take a look at flymake.el and jde-flymake.el. Together they provide on-the-fly compilation to JDEE. This makes for a nice complement to your module; you wouldn't have to do a full compile to get the compilation buffer in order to call qfix. As soon as flymake kicks in and detects the error, you would have enough information to decide which quick fixes to offer. You might have to make changes on how you detect errors since I believe jikes error messages might be slightly different then the ones from javac. I think this combination would get the whole environment even closer to what you found in Eclipse. Regards, Nascif -Original Message- From: Kai Grossjohann [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 7:03 AM To: [EMAIL PROTECTED] Subject: Investigating quickfix functionality I had been using Eclipse for some time a year ago. One thing I really liked about it was the quickfix functionality. When the compiler found an error in your source code, you could hit Ctrl+1 to pop up a little menu which suggested some remedies. Because I missed it so much, I investigate whether it would be possible to get this in Emacs, as well. It seems it would be possible in principle. This version only knows two kinds of errors: unreported exception, and cannot resolve symbol class Foo. I'd appreciate any comments or help or patches. What do people think? Kai
RE: Problem loading JDE in Emacs CVS
I upgraded to the SourceForge cc-mode, and after a lot of experiments, this is what worked for me: (add-to-list 'load-path (expand-file-name ~/emacs/cc-mode-5.30.9)) ... (load cc-defs) (load cc-fonts) (defvar java-font-lock-keywords-3 nil) (require 'jde) Very ugly, I know... :-( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, January 08, 2005 7:09 AM To: Nascif Abousalh-Neto Cc: jde@sunsite.dk Subject: 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
[ANN] jde-lint
Hi, I created a small packaged called jde-lint.el that provides an interface between JDEE (http://jdee.sunsite.dk/), and Lint4j (http://www.jutils.com/). Lint4j (Lint for Java) is a static Java source code analyzer that detects locking and threading issues, performance and scalability problems, and checks complex contracts such as Java serialization by performing type, data flow, and lock graph analysis. This package uses the information from your JDE project (sourcepath, classpath and package name) to run the lint4j tool and present the result in a compilation buffer. You can get it at: http://home.nc.rr.com/nascifandelaine/emacs.html Regards, Nascif PS: Paul, what would you recommend as the best way to keep links for contributed packages like this one? Is it OK to add a new page under the JDEE page in the Emacs Wiki? I think it would be better to have it all under the official JDEE page but using the EmacsWiki decentralize the efforts.
JDEE extension pages in the Emacs Wiki
I created pages in the Emacs Wiki for some of the extensions I wrote, plus the usages plugin. Regards, Nascif -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 11:38 PM To: Nascif Abousalh-Neto Cc: jde@sunsite.dk Subject: [ANN] jde-lint Hi Nascif, I have added jde-lint.el to the Contributed Software page on the JDEE website. I think it would be a good idea for you to add it to the JDEE Wiki page as well to make sure that JDEE users are aware of it. If you don't mind, I'd like to consider the jde-lint.el package for inclusion in the JDEE distribution as well. Thanks for providing this valuable contribution. Regards, Paul Nascif Abousalh-Neto writes: Hi, I created a small packaged called jde-lint.el that provides an interface between JDEE (http://jdee.sunsite.dk/), and Lint4j (http://www.jutils.com/). Lint4j (Lint for Java) is a static Java source code analyzer that detects locking and threading issues, performance and scalability problems, and checks complex contracts such as Java serialization by performing type, data flow, and lock graph analysis. This package uses the information from your JDE project (sourcepath, classpath and package name) to run the lint4j tool and present the result in a compilation buffer. You can get it at: http://home.nc.rr.com/nascifandelaine/emacs.html Regards, Nascif PS: Paul, what would you recommend as the best way to keep links for contributed packages like this one? Is it OK to add a new page under the JDEE page in the Emacs Wiki? I think it would be better to have it all under the official JDEE page but using the EmacsWiki decentralize the efforts.
Continous Testing
Hi all, I recently learned about this Eclipse plugin: http://pag.csail.mit.edu/continuoustesting/ The idea of this plugin is to use idle cycles to run your unit testcases - as soon as you finish a change, your unit testcases would be executed (perhaps just the ones for that class) to give you instant feedback on any bug you might have introduced. I was thinking on how to implement that for Emacs/JDEE. Perhaps an extension or hook for flymake could be used, together with a call to jde-eval - once we know the class is syntatically correct, we trigger the execution of the testcases. Or maybe a hook into semantics, since it also seems to do work in the background now. What do you think? Any ideas? /Nascif
RE: code completion from noncompiled classes
Hi Fredick, You can look at CEDET's Semantic intelissense feature, described at http://cedet.sourceforge.net/intellisense.shtml This implementation works only for files you have previously loaded in an Emacs buffer (so it would not be useful for the JDK classes, unless you manually visit all the source files) but it provides true code completion like jde-complete - without requiring compiled classes. There are also poor man alternatives, that don't provide true code completion but make up for that in speed. I use dabbrev-expand a lot, and once you get used to it it can be quite useful. I also played a little with predictive mode (http://www.emacswiki.org/cgi-bin/wiki/PredictiveMode) using a dictionary made of Java keywords and JDK class names. The latest version has support for regular-expression based dictionary switching, which perhaps could be expanded with some info from Semantic to create a more useful tool. The way predictive works (offering alternatives as you type) is very interesting, but it definetely needs to be better tied up to the Java syntax to be more useful. Regards, Nascif -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 11:24 PM To: Fredrik Skeel Loekke Cc: jde@sunsite.dk Subject: code completion from noncompiled classes Fredrik Skeel Loekke writes: is it possible to use code completion from noncompiled classes? It's possible but it would require a major coding effort to enhance the JDEE to do this. Paul
RE: Problem with nqmacs + jdee 2.3.5
I just tried it. ECB looks very nice too! -Original Message- From: Ping Liang [mailto:[EMAIL PROTECTED] Sent: Friday, March 04, 2005 12:29 PM To: jde-users Subject: Re: Problem with nqmacs + jdee 2.3.5 I found the cause of these problems. I still had jdee 2.3.4beta5 directory in my site-lisp directory. As soon as I removed that, the problems I mentioned went away. Thanks anyways. On Thu, 3 Mar 2005 10:24:17 -0500, Ping Liang [EMAIL PROTECTED] wrote: Hi, I decided to use nqmacs to take advantage of the new emacs features it provides. Since it does not work with jdee 2.3.4beta5 that I was using, I also upgraded jdee to 2.3.5. After this, jdee behaves quite differently. To name a few, 1) I noticed that jdb menu was not in the menu bar anymore. I installed jde-usage and it was not there either. Functions are still defined as I can still use them but... 2) I have an entry in my .emacs to add my own style, something like indenting only by 2 characters, etc. It does not work any more. It seems that all are default values. What I do is (add-hook 'jde-mode-hook 'my-jde-mode-hook). 3) The key binding for jdee is not longer there. For example, C-c C-v Cy would bring me to the definition of a method/class/variable. No more. However, things like jde-open-class-source would work if I execute it from M-x. While I can easily switch back to the old setup, the new emacs is just too attractive to give up. Anybody has the same experiences? Any help would be appreciated. Regards, Ping
RE: Re[2]: header line bugs and artifacts
Hi Eric,
This approach can also be overwhelming and frustrating - I saw it first hand
with some co-workers, having to stop their work to find out and turn off new
features they didn't want in the first place.
Another tactic might be to start with the more powerful features disabled and
provide documentation on them, including screenshots. Curious users will find
the info and tinker with them, and spread the word in wikis and mailing lists;
less sophisticated users won't be frustrated with all the colors and extra
fontification getting in their way, coming from nowhere, as soon as they
install the new library. They might them be more receptive to turn them on
later.
Best regards,
Nascif
-Original Message-
From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 23, 2005 8:46 AM
To: Felix Dorner
Cc: jde@sunsite.dk
Subject: Re[2]: header line bugs and artifacts
Hi,
Stickyfunc mode puts the first line of the method/class
that is on the top line of the window into the header line.
That way you can always see what function you are working on.
It's something I always thought would be useful.
The overline is simply a decoration to help divide
different types of tags from eachother in the buffer. I
copied the idea from some Java editor I saw a coworker using.
It is a part of semantic-decoration-mode. You can concoct
your own decorations with `define-semantic-decoration-style'.
I have seen several times that people look at these things
and go Eeww! What's all this? and after a little bit
change their minds and think they are useful.
You can turn all the code-helpers off and suffer no ill
effect. I turn most things on in the default so you get
exposed to them, and can later choose which tools you like
and turn off the others.
Eric
Felix Dorner [EMAIL PROTECTED] seems to think that:
That's the because of semantic stickyfunc mode. Try M-x
global-semantic-stickyfunc-mode.
OK thanks. With that, the header-line disappeared.
I guess it appeared because I have
(semantic-load-enable-code-helpers)
(as in the cedet INSTALL file), do I really need this?
another artifact that appeared yesterday too was an overline right
above a class body, just like this:
__
class TestSocket extends Socket{...
and a similar overline right above the main method of that class
So what are those lines meant for?
Felix
--
Eric Ludlam: [EMAIL PROTECTED],
[EMAIL PROTECTED]
Home: http://www.ludlam.netSiege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
Jde-help and wget
Hi, I was trying to configure jde-help to see some javadoc directories in Jakarta (the commons libraries) and I had to fix a number of problems in the process. Here is what I did in the hopes it might help someone else: 1) Once I enabled the extra docsets pointing to the jakarta javadocs, jde-help-symbol started to fail with a very cryptic message, something like wrong type, (sequencep, 2) or something like that . I traced it down to the method jde-help-find-javadoc, more precisely to this code: (if jde-help-wget-tries (concat --tries= jde-help-wget-tries)) I fixed by changing it to: (if jde-help-wget-tries (concat --tries= (format %d jde-help-wget-tries))) Same thing on the line below: (if jde-help-wget-timeout (concat --timeout= (format %d jde-help-wget-timeout))) 2) After that step wget was still failing on me - but then it was a local environment problem, since we use an http proxy at work. Adding a .wgetrc with the proper info solved the problem. It seems that jde-help tries all the docsets, even if it finds the help for the class at point in the first one. I believe this should be optimized - it is already a little slow as is. Regards, Nascif
