email@example.com http://www.deepbluelambda.org/programming/clojure/programming-clojure-with-vim Slimv Slimv is a relatively unknown plug-in in the Clojure community. It is written by Tamas Kovacs, and originated as plug-in for Lisp programmers. However, in the past few versions, it has begun to support Clojure. Slimv uses a Python script to launch a REPL, to which it sends commands in a way, in principle, not terribly unlike slime.vim. Instead of running a REPL using Screen, it launches the REPL in a new terminal. Unlike slime.vim, it seems like it supports a much greater amount of functionality, much like VimClojure. In fact, it supports having a REPL inside of Vim that has the potential to be vastly superior to the one provided by VimClojure. In particular, it allows using the arrow keys in insert mode to navigate the REPL history. Unfortunately, the current version is a bit buggy. For example, the REPL works, but after every command I get series of Vim errors that, although apparently harmless, make the experience intolerable. The latest version also includes a paredit plug-in, that promises some of the features of Emacs� paredit minor mode. Unfortunately, I found it fairly buggy. For example, in one case where I wanted to delete to the end of a line using D, it deleted my entire line. In another case when I wanted to move a one-line def using dd and p, I found that the p pasted nothing at all. Yanking and putting still worked, though. I think Slimv has some great features, but until some of these bugs are worked out, it is not going to be my plug-in of choice. Unfortunately, there does not seem to be a project page or repository available anywhere for Slimv. dakrone: I'm using slimv and I was wondering if there is a way to stop the "results buffer" from stealing focus ever time you eval a statement http://news.ycombinator.com/item?id=1415455 I wanted to update you, since you were so kind as to give me a good possible solution. I tried slimv.vim, and the experience is fairly decent. However, I quickly ran into annoyances and problems. I get a welcome message in the evaluation buffer that confused me for a while because I thought I needed to position my cursor next to the asterisk (my current sbcl default). It turns out my cursor needed to be at the end of the buffer in order for my evaluated command to be recognized. Then the asterisk prompt makes sense again. Growing pains, but this is a silly and easy thing to avoid for new users. I tried tossing in an easy form in a slimv-enabled buffer: "4". I ,e it, and now I am stuck in the eval buffer where my 4 was evaluated as 4. How do I get out? Ctrl-W Ctrl-W isn't doing the trick. After some messing around, I eventually figure out with consistency that I have to hit SOME key, like ENTER, in order to be "released" from the RUNNING state to switch buffers back to where I was editing. ESC is no help here, although you would expect it to exit a RUNNING mode in vim. I do not see any configuration to prevent me from being forced into the eval buffer, so I am stuck with this disruption to the workflow. I could not figure out how to cleanly quit out of vim and shutdown slimv, aside from issuing a (quit) and hitting ENTER a bunch of times in the slimv window. The less clean Alt-F4 works as well. I did a fresh installation of hunchentoot and all dependent packages from within my vim session. This turns out to be annoying in that some of those packages are so spammy that the buffer gives up refreshing (partly because it is so slow to display all the new scrolling text). ,z refreshes the buffer, assuming I am aware enough that it has given up and is not just pausing to calculate something. But the final kicker for me... The omnicompletion is both superficial and poor. It is superficial because it only supports common lisp symbols, not symbols actually in my current lisp environment. It does not support package prefixes either, so I cannot complete on any of the sbcl packages, much less anything I have installed. The linedit package does a super job of getting this right, and slimv could do it right with a little help from with-package-iterator instead of faking it. The omnicompletion is poor, even with the basic common lisp symbols, because "-" is not recognized as part of a word, so I am unable to omnicomplete forms outside of the first few letters. I am, however, able to use basic Ctrl-N/P autocompletion successfully in my lisp buffers with any symbols that include "-", so I am confident my vim is configured properly somewhere. Am I missing something to tell omnicompletion to recognize "-" as a word character? Basically, I feel like with slimv I get sluggish and fewer useful features than just using slime.vim. I really wanted some nice integration where I could have the slime experience of being within the lisp environment, able to introspect and so forth. The bundled paredit is decent for its bracket handling; that is something that will probably take me a lot of time to get used to. I have one significant complaint about it, though. It is great that when I type a closing parenthesis that the cursor moves beyond the already-provided parenthesis. It is much less great that when I type a closing double-quote, it adds a new pair - and good luck trying to delete one of the double-quotes once the pair is involved. It is even worse that I cannot toss in an escape on the double-quote within my string (try it! Can you type: "\"" ?). This makes the bundled paredit pretty unusable, far more annoying than just leaving it disabled. Is slimv even actually using slime? I saw the port configuration, but I really get the feel that we are just repeatedly reloading a tmp file in a buffer, and our hotkeys send direct lisp commands to an sbcl process wrapped by a python script. Taking a step back, I keep asking myself if this is all just whining. slime.vim (which is not slime either -- it should be called screen.vim or something) and linedit work well enough for me, given that they actually work as advertised. The other option for me is to just use emacs, but I cringe when I consider it; I have been down that road, and it felt like somebody intentionally made it difficult to actually do text editing in it. Thanks again for the slimv suggestion.