2010/7/19 Meikel Brandmeyer <m...@kotka.de> > Hello Laurent, > > please let me explain my philosophy before I go into details how VimClojure > handles the clojure connection. > > > 1. 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. > 2. The tools should *only *do what the user tells them to do. No more, > no less. > > Well, by activating the "automatic builder" feature of an IDE, I /suppose/ users typically think this is a way to tell the IDE to do automatic rebuilds. "rebuild" here meaning AOT compilation of the strict necessary files, and reload of what has been changed :-)
> 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. > > OK, so in spirit we're not so far from each other. I too try to minimize the impacts of the several moving parts on the "core part" that is the editor. > > 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. > You're right. This is another point. Currently there is confusion in ccw between a REPL and a "server instance". I intend to remove this confusion in the future, when really implementing the possibility of having several concurrent REPL clients on the same "server instance". > > As for a typical workflow of mine: > > > 1. gradle runNailgun > 2. Start vim > 3. open clojure file > 4. edit edit edit > 5. lookup some docs > 6. edit edit > 7. save ; Note: nothing happens here. The file gets saved. That's it. > 8. edit edit edit > 9. Send some code via \et ; „*e*val *t*oplevel“ > 10. Open a repl \sR ; „*s*tart *r*epl“ R meaning in the namespace of > the current buffer > 11. 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. ;) > Yes, I'll probably will have to content both styles of development. The good news are that one path is a natural step of the other :-) > 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<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- 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
