Nascif Abousalh-Neto writes: > 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. >
This is not true. I have developed two applications that use a socket for communication between Emacs and a Java process. The applications use process-send-string to send data to the Java process. It works fine. There is no need to shut down 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. 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. The only thing that Nascif is proposing to add is a Java wrapper around Lisp code required for the Java application to manipulate Emacs. 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. With Nascif's approach, only the functionality exposed by the wrapper code is available to the Java process. 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
