Lisp Programming with Vim (2019) | Hacker News Reader

Lisp Programming with Vim (2019)

susam.net

94 pointssusam17 comments

Only tangentially related; but tree-sitter, lsp and friends are actually some of the most exciting developments for lisp programmers because we are finally seeing a model where Emacs and IDE support for lisp can properly decouple. One of the in-practice problems I've seen a lot of in Clojure is that people aren't sure how to get a REPL set up and all the local experts are using Emacs. Which is lovely but "you'll need to learn Emacs for me to be able to set you up!" is not exactly the battle cry of easy adoption.

SLIME for Lisp exists since a long time. It has a server component.

From what SLIME provides, one can see that the functionality used for interactive Lisp programming is different what one would use for many other languages. One is not communicating with a "language server", but with the live running application and its embedded development tools. For a Lisp programmer it is interesting where a CLASS is in the source code, but it is slighty more interesting to interact with the live class object (a metaclass object). CLOS (the Common Lisp Object System) was designed for interactive programming. That's also why it is said to be a 'system' and not only a language.

I've pretty much ignored tree-sitter because Lisp is so easy to parse anyway. Does tree-sitter add value for Lisp parsing? Apologies; I really am coming from under a rock here.

Parsing to execute is easy. Real time parsing to do syntax highlighting and indenting less so. By convention people often implement some forms differently than others.

It isn't a crazy challenge, but the bar is higher than counting parens. And obviously Emacs doesn't do this correctly because it dies if someone throws a long line at it (the usual implementation of syntax highlighter is apparently regexp soup).

Apropos treesitter, lsp and friends, I have based my baseline Emacs programming experience [1] on these. Quite enjoyable!

Apropos Clojure IDEs, m'colleagues and I in my neck of the Emacs-using Clojurist woods tend to send newcomers to VSCode or IntelliJ [2].

As community surveys show over the years, these two have come to own big chunks of the Clojure IDE pie. Well-earned, because both have received excellent Clojure programming support, with smooth REPL integration.

It seems Zed could become a contender too. A long time Clojure programmer friend and die-hard Emacs user recently remarked how Zed's performance might win him over.

[1] https://www.evalapply.org/posts/emerging-from-dotemacs-bankr...

[2] https://github.com/inclojure-org/clojure-by-example?tab=read...

and

https://github.com/inclojure-org/intermediate-clojure-worksh...

> One of the in-practice problems I've seen a lot of in Clojure is that people aren't sure how to get a REPL set up

The most common "problem" I've seen with people starting to learn Clojure, is that they try to use the REPL approach you'd use in Ruby, Python or NodeJS, namely writing and running small snippets in a standalone REPL prompt, in another window/pane, then copy-paste that into their editor when they're ready. Then repeat that process while working.

While what you actually want to do, is connect your editor to the REPL, put the REPL in the background then evaluate code with a keyboard shortcut from your editor, and see the results in your editor. Once you've taught this to people, their eyes open.

For vim/neovim users, Conjure is great at giving a nice environment quickly and easily. https://github.com/Olical/conjure

For Visual Studio Code, I've heard bunch of people having success with using Calva, but haven't used that myself a lot so can't say how nice it really is. https://github.com/BetterThanTomorrow/calva

Then there is https://cursive-ide.com/ as well.

> While what you actually want to do, is connect your editor to the REPL, put the REPL in the background then evaluate code with a keyboard shortcut from your editor, and see the results in your editor.

In Lisp I would use both. In some Lisp IDEs (MCL, LispWorks, SLIME), evaluating from the editor actually can queue up the form into a Listener (aka REPL) tool. MCL did this by default, LispWorks and SLIME have commands for that.

In case anyone needs to hear it out there, Calva for VSCode is fantastic and it works well with the VSC vim bindings. It's not vim but you get something working out of the box and that's not a trivial thing if your goal is to get stuff done.

I was going to say, in 2023 I looked around and for Clojure at least Conjure seemed like the best option.

https://github.com/Olical/conjure/wiki/Client-features

Unfortunately, in the table linked above the CL support in Conjure is so-so. I'm curious what people use for CL or if it's still slimv/vlime.

I did a write up configuring Conjure with neovim here if that's something that's appealing: http://danielwilcox.uk/computers-log-0/

We still use slimv/vlime. At the end of that page it says Conjure doesn't support debugging, this is rather crucial for Common Lisp.

Is vim-fireplace dead for Clojure?

I don't think vim-fireplace is dead per se, but as a former vim-fireplace user, Conjure is just a lot nicer. It also helps that Conjure offers support for multiple languages, which enabled me to dabble with Fennel, Racket and Janet without having to install extra tooling.

Either LispWorks or Allegro Common Lisp, or eventually Emacs/Slime, anything else is going outside Common Lisp historical background and evolution.

Clojure with Cursive, for a similar experience in Clojure.

Or Raket if going down the Scheme route.

I love the level of details of this write-up.

It assumes nothing and tries really hard to avoid you any papercuts. I wish I had found when I tried to learn Lisp. Between learning the language and all the papercuts I just gave up like I did for so many other niche things that caught my interest.

and obligatory link for more editors ;) https://lispcookbook.github.io/cl-cookbook/editor-support.ht... (Emacs, Atom/Pulsar (very good support), Jetbrains, Sublime, VSCode (less good support yet), Jupyter kernel, standalone general-purpose Lem editor…)

I've written all my Lisp in Vim for the past quarter century.

Nowadays I'm experimenting with parinfer in Vim.

It's quirky. First off, it doesn't work well with the lisp mode autonindenting, so that has to be turned off. It doesn't handle some syntax like #; to comment out an object.

I rigged Ctrl-_ to toggle parinfer on and off.

More about the indenting. If you're in :set lisp mode, and you have this, say:

  (progn  
    (cond
      (foo bar)
      (xyzzy quux)))_   ;; <-- cursor here

If you hit Enter for a new line, it will do this:

  (progn  
    (cond
      (foo bar)
      (xyzzy quux)))
  _                     ;; <-- cursor here

In parinfer mode, though, that is counterproductive, because you control structure through indentation. Say you want to add a fallback (t 42) case to the cond. You just want dumb indentation that is not Lisp aware and which just copies the indentation of the previous line:

  (progn  
    (cond
      (foo bar)
      (xyzzy quux)))
      _                     ;; <-- cursor here

Whereby parindent will instantly move the parentheses:

  (progn  
    (cond
      (foo bar)
      (xyzzy quux)
      ))

So I have it that when parinfer mode turns on, :set nolisp is executed, and vice versa, when parinfer is off, :set lisp goes on.

Reply on news.ycombinator.com