>>>>> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
[...] >> 4) Based on (3), it can replace direct invocations of the JVM with >> jde-eval >> calls (which should make it much faster) >> PK> Yes. >> 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. >> Part of what you're searching for here doesn't really exist yet, at least not in a general form. As part of the discussion for what constitutes a pure Java API for allowing plugins to interact with Emacs we would want to include this specific feature (stream text to a compilation output buffer). PK> The JDEE's compile server and ant server each uses its own PK> compilation-mode buffer to display output from the BeanShell. This PK> is in addition to the comint (interactive user) buffer that is PK> used to start up the BeanShell. The reason that it is possible to PK> have multiple buffers interacting with the BeanShell is that Emacs PK> allows Lisp code to specify and change dynamically the process PK> output handler. The compile server and the ant server, after PK> sending a Java expression to the BeanShell, temporarily replace PK> the standard output handler with their own handler to handle the PK> result of evaluating the expression. My intention is to write an PK> eieio class called bsh-compilation-output-buffer that encapsulates PK> this technique. This would make it trivial for Java plugins to PK> create compilation-style buffers for handling compilation-like PK> output from Java. Critical to this technique I think will be some sort of implementation of java.io.InputStream/OutputStream or java.io.Reader/Writer on the Java side which would trigger that standard output handler switch. Could we also use a separate socket for this? Java could open a server socket and Emacs could connect to it to "download" the compilation output and stream it to a buffer. [...] >> 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. >> PK> I'll depend on somebody else to do this. I'd be happy to take suggestions and lead up an effort to create the Java plugin API. Why don't people start listing off pieces of functionality that we can start gathering into specifications as Java interfaces. Those interfaces, after iterating on their contents could become the initial versions of that API. >> Finally, how do we manage different versions of common Java >> libraries (like XML parsers) among plug-ins? >> PK> Good question. Maven (http://jakarta.apache.org/turbine/maven/) has its plugins declare library dependencies, and even allows you to have them downloaded for you automatically! We should have a look at the Maven codebase for ideas in that area. At a minimum it would be nice to take advantage of the library repository that's been set up already (I believe it's on ibiblio.org). /Nick
