Thanks for letting us know Meikel. These are similar issues that we have encountered with the jark client.
We are planning to rewrite it in Haskell (currently Python), I'm sure there will be similarities between a potential VimClojure client. I have tried to tinker with VimClojure but sadly never got it building with gradle+clojuresque. I will have another go soon. What version of gradle (and clojuresque) is VimClojure known to build with? Thanks, Ambrose On Sun, May 8, 2011 at 12:20 AM, Meikel Brandmeyer <m...@kotka.de> wrote: > Hi, > > Am 07.05.2011 um 16:48 schrieb Chas Emerick: > > >> We haven't started on a VimClojure nREPL fork yet. > >> > >> We should probably ask Meikel if he's already tackled it, there is a > "nrepl" tag on > >> bitbucket but it's about 6 months old. > https://bitbucket.org/kotarak/vimclojure/overview > > > > My recollection is that Meikel was a fair ways along in his nREPL > implementation late last year. Hopefully he can chime in as to what the > current status is of things there. > > Ah. Sad story. I already worked in the nrepl backend for vimclojure—as > Ambrose noted: there is a branch on bitbucket for that. However things > stalled. The reason is the client. There I have these stupid vim limitations > again: > > * It must be fast. > * It must be self-contained. > * It must work on Windows. *bleh* > > The first point kills a Java client. The JVM startup time is too slow. The > second kills netcat, curl and friends. The client has to understand the > protocol in order to know, when to stop the connection and terminate itself. > Until the client terminates vim will be blocked. The third point kills all > the “standard” scripting languages like Python, Ruby, Perl, you name it. I > don't want to add a 30Mb dependency when a 30k client was sufficient with > nailgun. > > So what I need is: A client understanding the protocol and looking for the > “done” message. It must be fast and small. So it will be likely written in > something like C, OCaml or Haskell and compiled to native binary. It doesn't > come with more dependencies than itself. > > I might come up with a C or OCaml version for the Unices, but I have > absolutely no clue about Windows programming. Something like OCaml would > maybe even work verbatim on Windows, but I haven't got native compilation to > work there. > > And finally I'm missing time right now to do this by myself. (As always… > *sigh*) > > When I read about jark+nrepl+cli client, I thought “*dumdidum* someone will > do it *dumdidum* someone will do it” ;) I appreciate any help and I'm > willing to help out with support on answering questions and posing > setting-hair-on-fire requirements. > > Sincerely > Meikel > > PS (general note): If you want to hack on VimClojure – especially with such > difficult and essential issue as a different communication channel – I'd > appreciate to be kept in the loop. I can save time by knowing caveats and > obstacles. And – frankly – I'd like to know what modifications of VC are > going on out there. Feel free to discuss such things on the VimClojure > goggle group. Thank you. > > -- > 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 > -- 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
