IMHO a very well-written article with great attention to detail. I especially liked the section on paredit with its step-by-step explanation.

I wonder why the author doesn't mention the plugin vim-slime, given that it seems to be more popular than either Slimv or Vlime on GitHub. From what I can gather, Slimv and Vlime are more focused on Lisp with built-in completion and debugging whereas vim-slime is language agnostic and simply recreates just the "connected REPL" behavior of Slime.

The "vim-slime" plugin is not appropriate for my blog post because it is nothing like SLIME. In fact, the word "slime" in "vim-slime" is poorly chosen. It supports none of the SLIME features. It does not even provide the "connected REPL" experience like SLIME, Slimv or Vlime does. Here are the major reasons why vim-slime is very limited and insufficient as a Lisp development environment when compared to SLIME, Slimv or Vlime:

1. It does not understand s-expressions. It can only send the current text paragraph or text selected in visual mode to a terminal running in GNU Screen, tmux, Neovim, etc. Therefore, it cannot send, say, only the current expression or an entire function definition or a top-level form to the terminal.

2. Since it is language-agnostic and really only sends text from a buffer to a terminal, it does not care whether the text is code or prose. It also does not care if the terminal is running a Unix shell or a REPL. It is the user's responsibility to ensure that the correct REPL is running on the terminal and the corresponding code is being sent from Vim using vim-slime.

3. Since it does not implement the client-server architecture that SLIME and Swank implement together, it has none of the interactive debugging features of SLIME. It cannot automatically launch the integrated Slime Debugger (SLDB) when an unhandled condition occurs. As a result, all debugging features like inspecting code, inspecting variables, etc. are missing.

4. Almost all of the SLIME features are missing from it. It does not support displaying argument lists as we type function calls, Common Lisp HyperSpec (CLHS) lookup and completion, describing symbols, cross-referencing, etc.

5. It does not provide any key-bindings for common tasks such as macro expansion, function tracing, etc.

Swank server is an integral component of SLIME. It is essential to the way SLIME works. A plugin that does not talk to Swank server can hardly be anything like SLIME. Slimv and Vlime on the other hand talk to the same Swank server that SLIME talks to. Slimv and Vlime are re-implementations of the client component of SLIME. They send SLIME commands to Swank just like SLIME does. As a result, Slimv and Vlime are able to support a good portion of the features available in SLIME.

Thank you for the explanation.

Such a great article.

I really wish though there is a button to turn on and off so one can read only about Slimv or Vlime or both.

This is great! I just recently started using Vlime and had been starting SBCL externally but your `\``r` `r` hotkey has just saved me lots of annoyance!

Same with the interactive debugging, I didn't know you could inspect the call stack like that and evaluate stuff! I only knew about choosing restarts. Thanks for this write up!

This is a great article! Thank you so much!

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.

Still the best article on setting up Vim with Lisp in 2024. Great resource!