As a long time Emacs and JDE user (I think I first started using JDE in 1997) I have 
to throw in my 2cents and say that I'd be hugely excited with any work made towards 
making plugins written in Java easy to integrate with JDE.  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. :)

>From the top of my head, these type of operations bound to a JDE plugin would allow 
>for some neat development:

  Input into the plugin:
     - class at point
     - object name at point
     - point context (what method, what class)
     - (user input data from minibuffer)

  Output from plugin:
     - direct output to new buffer with name..
     - direct output to new buffer in split pane
     - insert output into current buffer at position
     - some way of replacing current word with output?
     - display menu at point?

If you could bind lisp commands to a java plugin with the type of input then it might 
allow for a bunch of new development.  I for one would spend the time to do some new 
things.

-Nic

> -----Original Message-----
> From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 19, 2003 8:35 AM
> To: Paul Kinnucan
> Cc: [EMAIL PROTECTED]
> Subject: RE: JDEE plugins (was JUCI)
> 
> 
> Hi Paul,
> 
> Just to recap:
> 1) The plug-in will follow the proposed directory structure;
> 2) It will have a lisp/plugin.el file that will be evaluated 
> at load time by
> JDE (still not sure what goes here, any suggestion?);
> 3) It can assume that its libraries will be in the BeanShell 
> classpath;
> 4) Based on (3), it can replace direct invocations of the JVM 
> with jde-eval
> calls (which should make it much faster)
> 
> Problem with (4) is how to get the output to a compilation 
> buffer. When I
> launch a new JVM process myself, I can just redirect the output to any
> buffer I choose; if I launch the Java portion of the plug-in from the
> BeanShell, the output goes to stdout, which is captured as 
> lisp forms by the
> BeanShell, right? Sorry if that is a basic elisp question, 
> but how do I
> redirect that output to a compilation buffer? I guess I could 
> use that code
> you mentioned. I looked at the code at jde-checkstyle.el for 
> an example but
> my impression is that it launches an new JVM for each 
> invocation instead of
> using the BeanShell, is that correct? As a first pass it 
> should be OK for
> the plugin to do the same, but then we will be missing an 
> opportunity for
> code re-use.
> 
> I agree with the others that the less elisp requirements we 
> have the larger
> will be the pool of plug-in contributors; I believe JUCI will 
> be able to
> help us with this part; maybe some elisp code generation 
> facility based on
> Java Reflection or config files could also complement it. 
> 
> I think the final design goals should be:
> 1) "Drop-in" install; just adding a jar or zip file to a 
> specific directory
> would be sufficient to install the package and integrate it 
> with JDEE menus;
> 1.1) With a plug-in manager menu to enable/disable plug-ins;
> 2) Minimal to none elisp code required. I think we will have 
> elisp-based
> plug-ins as well, but I expect most to be Java-based - just 
> because most
> JDEE users know Java much better than they know Lisp.
> 
> What would be the list of "resources" available to the Java 
> code in the
> plug-ins? Any ideas on how to make Emacs/JDEE resources like 
> buffers, point
> position, region content, files in sourcepath, etc. easily 
> available? Maybe
> a basic class that they could extend? We have to define the container
> environment for the plug-ins.
> 
> Finally, how do we manage different versions of common Java 
> libraries (like
> XML parsers) among plug-ins?
> 
> Regards,
>   Nascif

Reply via email to