As a vim user, I am definitely open to good vim environment options for my lisp experiences. My attempts to use current solutions have so far been poor, for what it's worth; every solution seems frail, to break when I use just the wrong key. Suddenly vim is screaming at me, and some background process that handled the connection to a lisp has died or is unreachable by vim.
I use slime.vim (yay for vim and screen), but there is something to be said for being able to have what amounts to intellisense for dynamically declared functions, to have the experience of working actively with symbols within packages.
As the author of the article points out, the key sequences for working with lisp are ugly (long). And I would point out that in emacs, almost all key sequences are ugly.
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.
My opinion of emacs configurations[2] is that they are incredibly elaborate jenga towers; 30 or 40 odd years of scripts balanced with utmost care on top of each other. As i mentioned in a previous comment ive stopped trying to maintain my own clumsy pile of jenga blocks and have used technomancy's emacs-starter-kit. So far i'm happier than i've ever been with an emacs install[3].
so, in an attempt to avoid letting the success i had on monday evaporate.
0) grabbed a recent emacs 23 for mac os x (not aquamacs at various suggestions).
1) grab the emacs start kit; its targeted at dynamic languages in general, not just clojure. It is a replacement for your ~/.emacs.d/. It includes elpa, the package manager thing. M-x package[tab] will list all the functions in the package manager.
2) grab a cheat sheet and attach it to a surface near your screen. refer to it often.
3) i have not even tried to use slime and swank. emacs and paredit are enough of a learning curve for me at the moment. I use lein from the shell to access my repl, git from the shell for managing my repo.
4) install clojure-mode via elpa if you are dabbling in clojure. apparently its not part of the default starter kit. M-x package-install [enter] clojure-mode [enter] i believe.
I'm happy with his because im learning the keybindings for emacs and paredit without having to worry about futzing with the emacs setup. paredit is already proving to be a great mode for editing clojure (or lisp in general i guess) code that its improved my life vs textmate. maybe in 6 months i'll look at tinkering with things some more.
[1] I used emacs at uni for about 5 years, and later at a job for a couple. At no time was I happy with my emacs set up, merely content that it was working. [2] bound to be hated by those who are fluent emacsians; sorry guys its just how it looks from where im sitting. [3] I'd still be using textmate for clojure if i hadn't heard about paredit. Maybe when counter clockwise gets a bit more love i'll have another look at using eclipse for my clojure code.
[edited:formatting]
1. Windows opening and closing seemingly at random when using SLIME 2. Horrible default fonts 3. Unfamiliar keybindings, some of which are awfully long keystrokes to do very common actions, e.g. C-x C-f to visit a file, C-x C-s to save a file. 4. Struggling with Emacs jargon and navigating the help system
There was a lot more. Part of the problem is that none of these things bother me any more, because I've drilled them into my brain over the past two years. So I don't remember everything I struggled with. I just remember being extremely frustrated.
For the most part I never found solutions other than getting used to the Emacs way of doing things, and changing my habits.
A (true) anecdote.
I use a piece of custom software at work. Parts of it are horrible to use, truly awful, unintuitive, time-wasting.
For those of us who've used it for a year or more we ignore the rough edges. We know that when you perform a certain action a pointless warning box appears so you immediately hit 'Enter' to dismiss it before it even appears. Obviously we know what the menu entries do, even the ones with no text label.
We were forced to use this software at a point where we couldn't fix it. Now we have the ability to fix it but we've changed our habits to fit it so we don't bother even filing bug reports. New users, however, are going completely crazy trying to learn it.