On 2006-01-19, Brad Beveridge <[EMAIL PROTECTED]> wrote: > Some more info on netbeans: I got this back from Xavier de Gaye, the > author of Clewn. > "Clewn pretends to be an IDE and controls gvim: open files, > highlight lines and even do some buffer editing for the watched > variables window and assembly buffers. [snip clewn details]
> So, as I see it gVim (console vim doesn't include netbeans at this > stage) has a well defined, socket based protocol for interacting > with an IDE. [snip, I think] > Originally this was used in conjunction with Java Netbeans to let > you use gVim instead of the regular editor. Part of that interface > lets an external program modify Vim buffers, and buffer updates can > be sent from gVim to the other end of the protocol. It sounds, then, like we could send arbitrary strings down a socket, and get arbitrary strings back again, using the Netbeans interface. I couldn't figure out how to do that from the Vim help file. I guess we'd end up with a more Emacs-y approach and have a buffer that Netbeans appends to, and we read text from the top, and vice-versa. *thoughtful frown* I'll have to re-read the Netbeans help file. One thing I like, though, about a separate, stand-alone, Perl module is that it's not strongly tied to Vim, and you could use it to programatically control a Lisp over a socket, with full support for the debugger and so forth. So the Perl module would have a wider usefulness than just as a backend for Vim. Using the Netbeans interface would, it seems to me, strongly tie us to Vim and not provide any functionality outside of Vim. On the other hand (I have lots of hands :), I guess the chances are good that most people that wanted to control a remote Lisp would either just use Emacs+Slime, or would (duh) use Lisp, not Perl. So maybe the stand-alone module idea doesn't give as much extra benefit as I'd thought. > I think that it is worth looking harder at the gVim netbeans > interface (I'll probably rip Clewn apart until I understand how it > works). If Netbeans is strong enough - and it ought to be, a GDB > frontend uses it - then we may be able to significantly reduce the > workload & remove the need for a Perl module > 1) Implement Netbeans communications in Common Lisp (Hmm, what > socket lib to use?) > 2) Port some/all of slime.el to Common Lisp,integrate it with the > Swank backend & make it talk to vim via the Netbeans interface. As Peter pointed out, we should tread lightly when approaching the SLIME team about this idea. It seems to me that, at most, we should distribute a slime.lisp (or whatever) and label it as "compatible with such-and-such version of Swank" (or more likely "compatible with the mm/dd/yy version of Swank from CVS"). Tell them what we have, and if they would like to include it into SLIME, then okay. > 3) There is no reason not to also keep the Swank port open. There might be. I know SLIME can talk to multiple Lisps; can Swank listen to multiple SLIMEs? > I don't know if this is a reasonable idea yet, but if it is then > maybe we should ask the Slime guys what they think. Emacs also > supports Netbeans, assuming no loss of functionality, Slime could > possibly support Vim and Emacs via Netbeans. That'd be interesting. :) Probably not that much change for slime.el, either; the communication layer is fairly small and well defined. -- Larry _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
