I learned Clojure + Emacs + Evil-mode + nrepl.el at the same time a few months ago and haven't really changed anything about my workflow since then.

This is how I start Emacs:

    * Open emacs
    * `c-x c-f` to navigate to and open my clj file
    * `c-c m-j` to start nrepl session (opens up in a pane split)
    * `c-w h/j/k/l` to move between windows
    * `m-x find-file-in-project` (I mapped to `;a`) to navigate to 
      other clj files in the git project

And this is my workflow once I have source file and nrepl split-panes open:

    * Edit code
    * `c-x c-e` to eval the expression above cursor
    * `c-c c-k` to eval entire source buffer
    * `m-hyphen c-c c-z` to load source file 
      namespace into nrepl window which I rarely do

I actually rarely use the repl window since you can eval code in the source file.

* I pretty much treat my source file as my repl and use `c-x c-e` to execute the previous form. (Screenshot: http://dl.dropbox.com/u/51836583/Screenshots/l0.png)

* Also, I'll often put the code I'm trying to get to work like `(my-func 1 2 3)` at the bottom of my source file. Then, while I'm hacking on `my-func`'s implementation, I mash `c-c c-k` (eval buffer) which returns the result of the last expression in the file.

* Another nice way to utilize `c-c c-k` is to put your `(assert (= (my-func 1 2 3) 42))` tests right into the source file. The tests will get run every time you eval the buffer. It's a solid test-driven loop baked into the core library!

(See more nrepl keymappings here: https://github.com/kingtim/nrepl.el#keyboard-shortcuts)

Most Clojureists write code they want to keep in their source file, and then evaluate it by using their editors tooling to send it to the REPL from there. I usually just type things into the REPL for one-off exploration or experimentation.

What editor are you using? Emacs certainly has had the most mindshare so far, but it's a beast to get started with. I recommend CounterClockwise for non-emacs folks: it's got all the features you need to be effective, and has full integration with Leiningen.

As far as errors and error messages; yeah, it's hard, and a lot if it is just getting experience. But one thing that will really help you out is to write your program in very small chunks, and test each part as you go. That way, when something goes wrong, you'll have a very good idea about where to start looking.

You do need to try using Emacs and nrepl. Actually, the best thing would be to watch an experienced lisper work.

It's not just about the REPL and syntax highlighting. You need to see someone use paredit (things like paredit-raise-sexp or paredit-forward-slurp-sexp), evaluate expressions in-place (either seeing the results in the minibuffer or inserting them into the code), use M-. to instantly jump to anything that is defined in the active runtime, etc.

As for debugging, the Clojure experience is pretty bad, compared to (for example) Common Lisp. I'm experienced and use Clojure every day to write large applications, but I still stick to logging for most debug work. And yes, backtraces are horrible.

This project can help with printing statements: https://github.com/danielribeiro/print-foo/tree/prit

Which is helpful for quick inspection.

For those not familiar with Emacs, IntelliJ IDEA with La Clojure is also an okay choice. I use IDEA for Python, Java and Scala; and still switch to Emacs when I code in Clojure. The reason is that Emacs has really strong toolset for LISP, where many of the features are missing from other environments, or implemented partially.

Slime/swank (nrepl replaces it, but I'm just slowly transitioning to it), provides code completion, documentation lookup, REPL, macro expansion and even live code updates on a running application; which can be a bit of a pain to setup on other editors. And the integration in Emacs is really great, as the repl buffer is really just a text buffer, the same as the one you are coding in.

But the biggest reason for me to code LISP in Emacs is paredit. It really makes all the trouble with balancing parenthesis and moving around the sexps really easy. It might seem counter intuitive and a bit troublesome at first, but I really recommend you to try it. For a short and enthusiastic video on paredit, see http://www.youtube.com/watch?v=D6h5dFyyUX0 -- and maybe the other Emacs Rocks! videos to learn more about modern Emacs.

On Emacs, I've been a long time vimer and one day I decided to try Emacs to see the world from a "higher order". First thing that I found superior to vim is that the level of extensions are beyond what vim mods could do. Being benefit from elisp, emacs can do pretty much anything your OS(unix) does, with the emacs interface on top of it. That means, you can use emacs stuff all over your "buffers"(working windows). And if you are a coder, you will be amazed by: 1. being able to code, while talk about your code on irc/freenode seamlessly; 2. being able to code, while open a api website, and move code examples between them. And things do not break easily like vim does, yet everything are an order more finished and intelligent than the vim counter parts.

Saying all these, the reason I am still using vim is that my CTS prevents me from using emacs all the time, and most of the advantage Emacs brings can be achieved by a good tiled windows manager such as xmonad.

One of the big things we'd like to accomplish is building a book out of things the community needs. I've felt this pain myself. I'd strongly suggest you submit "idea" issues for the topics you feel most uneasy about.

https://github.com/clojure-cookbook/clojure-cookbook/blob/ma...

Many good responses about using emacs. For those who prefer vim, you can use ScreenSend and paredit to get a similar experience (and there are other options, but that's what I use).

O'Reilly is has been flexible enough to let us crowdsource this and release it freely to the community, but as far as the commercial sales of the print version go, we're following a fairly traditional publishing model.

What author royalties there are will go towards getting print versions of the book to our largest contributors, and then to Ryan and I as editors.

I don't think it would be feasible to split the royalties fairly amongst all our contributors; not only would it be a large overhead, but the actual amounts would be pretty tiny unless you've written a pretty large proportion of the book. And if you do that, we'd be happy to talk to you about sharing some of the royalties.