1. 10

  2. 4

    When I worked with Clojure in Vim, I preferred vim-sexp over paredit.vim. I remember that Paredit forced that parentheses always be balanced. It clashed with my workflow of deleting a snippet of code (sometimes unbalancing parentheses) and then pasting it somewhere else in the file (making the parentheses balanced again). vim-sexp provides the same slurp, barf, etc. commands as Paredit without imposing that restriction.

    If you use vim-sexp, you will probably want vim-sexp-mappings-for-regular-people as well.

    1. 3

      I use both vim-sexp and vim-sexp-mappings-for-regular-people but I also use parinfer-rust. https://github.com/eraserhd/parinfer-rust It is by far the best application of parinfer I’ve come across. If you have tried other versions before and didn’t care for it I would suggest giving this one a go. It uses “smart mode” I think they call it, and it just works. I couldn’t stand the emacs version but this one made my transition back to vim so fun and simple.

      1. 3

        At least in Emacs, Paredit also provides bindings for deleting whole sexps, so you don’t end up with that issue. For instance, in

        (let [x 5
              foo (fn [y]
                    (+ y x))]
          (foo 8))

        if you position your cursor after the 5, you can do C-M-k (kill-sexp) twice and pull out both the foo binding and the fn expression onto the clipboard. It’s a bit of a different approach, but it means never having to do that cleanup work of balancing parens.

        1. 2

          Yeah paredit is the thing I’m most likely to change. I’ve heard of vim-sexp but haven’t used it yet!

        2. 4

          From my brief time in Clojure: Rainbow parentheses coloring is a must.

          1. 3

            Rainbow parens are a lot like training wheels; they make it seem easier for beginners by helping you out when counting and balancing parens, but the trick for actually reaching mastery is to have the computer balance parens for you and for you to ignore them.

            1. 2

              I used the paren shortcuts in Cursive, so I seldom used them for counting/balancing parens. Rainbow parens were helpful to visually break up the horribly nested expressions I was forced to deal with.

            2. 2

              Yeah, I too was hoping for some substance to go with the title.

              1. 5

                I didn’t mean it to be sarcasm since he didn’t actually mention rainbow brackets, but understand where your point lies. The post could read like “it took me 3 months to make Vim a decent Clojure editor.” Personally, I’m a little tired of making Vim a decent editor in whatever environment I’m thrown into and some businesses are very touchy about bringing in plugins. I mainly just use IDEs now and them whip out my Vim mastery only when it’s needed.

                I wish he’d talk more about Spec or other Clojure specifics. Maybe a followup article is in the works?

                1. 2

                  I wrote about my environment setup because I’d only managed to find a couple of decent posts about it that helped me.

                  I’ll definitely post a follow up, but I decided 3 months wasn’t enough time to really form much of a deep opinion about a language, and there are already tons of “first impression” posts.

                  And things change so quickly too. I’m at 5 months now, and what I knew about Clojure when I actually wrote this post as opposed to now is pretty different; useful functional patterns keep emerging, more exposure to popular or commonly used libraries, Java interop vs Clojure-y layers, etc. So I’m glad I didn’t try to tackle that in this post.

            3. 3

              The title misled me, I was a bit surprised by how much this focuses on the dev environment as opposed to software development best practices with Clojure / transitioning to Clojure from other languages. But I guess there’s already been a lot written about that.

              1. 3

                I mentioned above that I deliberately kept it focused on the environment setup because I hadn’t found many decent posts about using Clojure with vim that I found useful, so I wanted to leave something that may be useful for someone else.

                But yeah, thinking about it now, the title should’ve been something else.

                I’ll do a follow up later on where I dive deeper into my experiences with Clojure and functional programming so far, but I wanted to get a bit more time under my belt before doing that because I don’t feel like 3 months is enough time to really gauge that beyond a superficial level.

              2. 3

                As a Perl survivor myself, I’m glad you were able to escape it. ;)

                1. 2

                  Note: There’s a language server for Clojure available too [1]

                  [1] https://github.com/snoe/clojure-lsp

                  1. 2

                    I also created my own colorscheme, check it out. https://github.com/JpOnline/vim/blob/master/vimfiles/colors/custom_(based_on_jellybeans).vim

                    I don’t see myself using a light background, but I also enjoy not that many colors.

                    1. 2

                      So I don’t use color schemes, being sucked in by the movement to use no syntax highlighting, but your comments confused me. One reason I use black backgrounds and white text is to ease the strain on my eyes and save my eyesight as I get older. Is this contrary to your experience?

                      1. 1

                        Correct. When working late at night I’ll use dark backgrounds for basically everything, but during the day at work, everything is bright; slack, web browser, docs, the office around me, etc. The contrast from a dark terminal to everything else seemed to be the source of strain on my eyes.

                        So now when my eyes constantly swap from a terminal to my browser, they’re not constantly readjusting from something bright to something dark.

                        At least that’s the theory, and there seem to be others who have found the same thing.