>>>>> "GB" == Graham Bennett <[EMAIL PROTECTED]> writes:
[...] GB> As for the JDEE <-> Java interfacing issue, it's quite a difficult GB> one. The approach I took was drawn from the Transmogrify way of GB> doing it - all the logic was on the Java side and there was an GB> interface to get basic information (cursor position, selection) GB> from Emacs. This is probably the simplest approach, but it's not GB> the best since JDEE will have no input into the control flow at GB> all. It basically sends it a file and receives back a new one. As long as the AST resides in Java then it's pretty much the only way to do it, right?. I think with clever hook interface design you could allow the editing to occur in the JDEE while the determination of what changes to make would occur in Java. For example, a couple of methods like: void replaceRegionWithText(String newText, int begpos, int endpos); void replaceSelectedText(String newText); void insertText(String newText, int pos); As long as you use Emacs to edit the buffer and make the textual changes of the refactoring, you'll benefit from undo. This is starting to get off-topic, so we could take it offline. Also, most folks are going to want to use their cc-mode settings to format the code; that's what I don't like about refactoring engines that want you to configure pretty printers (e.g, JRefactory). GB> I suppose a nicer approach would be to have all the logic in Lisp. GB> One could go as far as having a Java component which walked the GB> AST producing Lisp. This AST could then be refactored and sent GB> back to the Java code to be printed. Maybe once the next generation of semantic is available we'll be able to do the entire refactoring engine in elisp, but until then, I think letting Java drive the control flow is OK as long as it can query Emacs for file/buffer info and let Emacs do the textual editing. Just a few thoughts of my own, /Nick
