>>>>> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
PK> Hi, You and others have raised two related but separate issues: PK> one is the need for plugin-in support and the other is a need for PK> a way to extend the JDEE that requires only Java programming PK> skills. My proposal addresses the first. I believe Nick Sieger's PK> JUCI addresses the second. Perhaps Nick could chime in and explain PK> how. So far, what I've done with JUCI allows Emacs and Java to communicate in a consistent and general way, providing a layer of abstraction above raw lisp forms printed on standard output, beanshell execution and the like. My current code in the JDEE CVS (lisp/jde-juci.el) has some very rudimentary examples (mostly unit tests), so what's there is just a shell at this point. Although it's quite easy to envision what's coming next, namely, a general interface that Java plugins could code to for receiving input and sending output, much along the lines that Nic Pottier has already started to enumerate. Let's continue to gather and take inspiration from other plugin APIs as to what sort of pieces of data need to be exchanged. 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.? >From my perspective, it'll be interesting to flesh these issues out further. Following a standard API/JSR would be ideal, but if that doesn't even exist yet, it will be hard. Also, it's going to be difficult to abstract away Emacs' tried-and-true concepts like buffers, windows, etc. The API is probably going to end up having Java objects called Buffer, Window, Frame, etc. /Nick P.S. For some technical notes on JUCI, have a look at the file java/src/jde/juci/package.html in CVS, or ask me and I'll send you a copy.
