Hello Laurent, please let me explain my philosophy before I go into details how VimClojure handles the clojure connection.
Vim is not an IDE like Eclipse or Netbeans. It is an editor which can be used with other tools to form an IDE, but on its own it is not. The tools should only do what the user tells them to do. No more, no less. While Vim's reality started deviate from these ideals long ago, I still feel that this is True Way™. And this is reflected in VimClojure's way of handling things. So what does VimClojure's architecture look like: There is of course Vim itself. It sits there. Does nothing. Waits for user input. Then there is the server process running separately. It listens for connections from the Vim side and runs the requested commands. In particular you can arbitrary many repl, doc lookup, evaluation, whatever connections in parallel. You can forward the connection via ssh and you can embed the server in any application you can think of. I had both success with a web app and a swing app. The client, which Vim shells out to, to plumb both parties together. The client-server connection works via a modified nailgun, but that's an implementation detail. All this degrades gracefully and is not required to run a vanilla vim with syntax highlighting, indentation and builtin static completion. Doc lookup, code eval, macroexpand, etc. are just supplementary to the core tasks available also without the server. One consequence of this architecture is that there is no continuous connection between both sides. However this is the only way Vim can handle such communication in a portable and stable way. The downside is that we cannot use interactive commands since the interaction is split over multiple connections. The upside is that one side going nuts doesn't affect the other too much. I can simply restart the server in the background with the Vim side noticing it, if the server goes banana. Some reloads and I can go on. Starting the server is up to the user. Rule 1: Vim is not an IDE. There is a plethora of tools for handling classpaths questions. I personally use gradle; before that I used simple shell scripts with project relative CLASSPATH and that's it. ant+ivy, maven, leiningen, … all will they do a sufficient job. Vim is an editor. It has no business with Java classpaths. (For eclipse this is different: eclipse is expected to handle the classpath, no?) Besides that, you cannot portable start a background process from inside vim. (At least I'm not aware of how to do that) I'm not sure I understand what you mean with „REPL“. I suppose it means „server instance“ in my settings. In that case there is only one. But it is not a repl. You can connect to it to obtain a repl connection (keeping book of the repl state etc.). But it is not in itself a repl. As for a typical workflow of mine: gradle runNailgun Start vim open clojure file edit edit edit lookup some docs edit edit save ; Note: nothing happens here. The file gets saved. That's it. edit edit edit Send some code via \et ; „eval toplevel“ Open a repl \sR ; „start repl“ R meaning in the namespace of the current buffer repeat 3. - 10. as needed You might note point 7: I do nothing on the server side on file safe. If I added function, it just isn't there for completion, yet. Only when I tell VC to evaluate the function via one of the \e* functions it is available for omni completion. I can live with such an inconsistent state, because I normally work on a very restricted set of functions. As soon as they are done, I do a complete sync by reloading the whole file etc if necessary. VC tries hard to keep line numbers as close to a synced state as possible. And as I said: if I mess up too much, I nuke the server and restart it without impact on my running vim. On the next interaction the namespaces are loaded cleanly from disk. I agree with Chas, that strange things can happen. Imagine a pre-defonce-semantics-for-multimethods clojure version: you could loose your whole method definitions by a innocent looking file save. I prefer the „Launch rockets“-button to be more prominent. ;) Puuh. I'm sorry this got so long, but I think I had to provide the necessary context to understand the why things are as they are with VimClojure. I hope I could answer your question. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
