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
