
Lisp Programming in Vim with Slimv or Vlime - gitrebase
https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/
======
dcassett
IMHO a very well-written article with great attention to detail. I especially
liked the section on paredit with its step-by-step explanation.

------
Seirdy
Also check out Fennel, a lisp that transpiles to Lua [0]. Lua is a first-class
scripting language for Neovim.

A previous article on using Fennel for lispy Neovim configuration was posted
here a week ago [1].

[0]: [https://fennel-lang.org/](https://fennel-lang.org/)

[1]:
[https://news.ycombinator.com/item?id=21676606](https://news.ycombinator.com/item?id=21676606)

------
marcrosoft
Anyone interested in this article should consider giving Spacemacs a try.

It worked out of the box for me and so far is the best setup I've found for
Vim users learning Lisp. I tried (wasted time with) all the Vim lisp plugins.

------
throwaway269329
TLDR; Slimv and Vlime support SLIME like development environment for Lisp in
Vim. They have similar features but their implementation details and key-
bindings are different. The OP prefers Slimv more than Vlime.

But I think the OP needs to add a disclosure that they are also contributor to
Slimv -
[https://github.com/kovisoft/slimv/commits?author=susam](https://github.com/kovisoft/slimv/commits?author=susam).

Open source contributions are good. This is a good thing. But this needs
disclosure because they could be biased towards this plugin consciously or
subconsciously.

~~~
susam
Fair enough! I did contribute to Slimv but if you see the commit history in
the link you have shared, all commits except the first one were made in the
last one month. That's because I contributed these commits while writing this
blog post. As I wrote down the steps and commands to work with Slimv in this
post and double-checked that they really work by trying them out in Vim, I
found that a few things did not work correctly. So I kept fixing those issues
in Slimv as I continued writing this post.

What I am trying to say is that I preferred Slimv even before I began writing
this blog post or contributed those fixes. More than being a contributor of
fixes to Slimv, I have been a happy user of it. Of course, my preference for
Slimv and my contributions to it could be correlated.

------
dang
Related submission on Slime for Vim:
[https://news.ycombinator.com/item?id=21729718](https://news.ycombinator.com/item?id=21729718)
(but no comments)

------
lancebeet
I wonder why the author doesn't mention the plugin vim-slime[1], 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.

[1] [https://github.com/jpalardy/vim-slime](https://github.com/jpalardy/vim-
slime)

~~~
susam
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:

\- 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.

\- 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.

\- 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.

\- 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.

\- 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.

~~~
lancebeet
Thank you for the explanation.

------
nafizh
What would be a good resource to learn Lisp in terms of problem solving or
doing projects? I feel I only learn something when I use it to solve a problem
in the real world.

~~~
mtreis86
Practical Common Lisp is very accessible for learning and quite project
focused. [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

------
travislane
Two questions:

With the advent of capable editors like Visual Studio Code, is Vim still a
relevant skill to have?

Is SLIME still the state of the art for Lisp development environment? Is there
no way to get started with Lisp programming without having to learn Emacs or
Vim?

~~~
F-0X
Here's one maybe-reason and one definitely-reason VSCode cannot replace vim
for me:

1) Logs are often compressed. Can VSCode open .gz files? Vim behaves
pleasingly unixy: 'zcat logs.gz | vim -' opens the file pretty quickly in vim.
No fuss with explicit de/recompression. This also ties in to the usual "but
ssh" argument, since of course you're likely to be getting logs on remote
machines.

2) Bash pipelines are usually an iterative affair. It has some tricks in place
to mitigate the issues of very long commands. C-x C-e will open vim to allow
you to enter a command, and fc will open vim with the previously executed
command already there (short for fix command).

Lastly, vim has an expansive collections of extensions. So much so that if vim
is ever "not enough", then neither is VSCode, and I should just use a full
IDE.

~~~
harryposner
A slight correction: C-x C-e and fc open $EDITOR, which is vim by default on
most machines. You can change it to anything, though.

------
z3t4
It feels wierd to write this as im stumbled how so many people prefer video
content over text. But I would like a video to see how this looks like in
practice.

~~~
susam
Slimv tutorial has static screen captures to show what the Slimv experience
looks like:
[https://kovisoft.bitbucket.io/tutorial.html](https://kovisoft.bitbucket.io/tutorial.html).

Vlime README has a terminal session recording that provides a quick demo of
the plugin:
[https://github.com/l04m33/vlime#readme](https://github.com/l04m33/vlime#readme).

