Hacker News new | past | comments | ask | show | jobs | submit login
Lisp Programming in Vim with Slimv or Vlime (susam.in)
85 points by gitrebase 72 days ago | hide | past | web | favorite | 42 comments



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


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/

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


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.


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.

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.


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.


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


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


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.


Thank you for the explanation.


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.


Practical Common Lisp is very accessible for learning and quite project focused. http://www.gigamonkeys.com/book/



Vladimir Sedach's "Common Lisp is the best language to learn programming": https://oneofus.la/have-emacs-will-hack/2011-10-30-common-li...


I’m making a static website in clojure, which is how I managed to get myself to learn some lisp.


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?


Vim, the text editor, might be relevant if you want a powerful text editor that's installed on basically any *nix system ever. Nano has become nearly as ubiquitous so it's unlikely that you'll need to know vi/m on most hosts these days.

Vim, the editing paradigm, is a relevant skill if you value trading time to learn a way of editing text that is vastly different from traditional. It's a faster way of editing that once you grok it will probably make you annoyed about editing text in editors that don't support it. VS Code has a pretty good vim implementation, though. I personally think it was worthwhile, but people value different things. You might not like the investment of time it takes to become proficient or may not find it as useful as I have.

I can't speak to what is the state of the art for Lisp development. I'm confident that you can use editors other than Emacs or Vim for it, though.


I have no idea why you were downvoted for your questions. Weird. I will try to answer your questions:

One killer application of Vim and Emacs is development on powerful remote servers, for example, you might want 16 cores, a powerful GPU, and 64gig memory for a task so remote exploration and development makes sense. (VSCode does have a remote mode but I haven’t tried it.)

I have been using Emacs for 20+ years with Lisp. I just use Vim for quick edits to I can’t speak to using Lisp dev Vim support.

For local development on my laptop, I now use Emacs or VSCode about equal amounts for Common Lisp, Racket, and Haskell depending on what I am doing. Both are fantastic dev environments.

EDIT: Slime may be old, but it is tried and true technology. LSP is more modern and is a common autocomplete, etc. interface for many languages.


Just want to mention since it's not obvious from your comment, that there are both Vim and Emacs plugins to offer LSP support, and also Neovim is getting a built-in LSP implementation.


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.


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.


I just use zless and then press v to invoke vim if I need to edit. I don't usually edit logs, mind you. But for other .gz text files, that I might read and then decide on a whim to edit, definitely.


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

That's such a weird dichotomy to present, what feature of Vim did other text editors lack that VS Code managed to replace? Vim is a "relevant skill" because it is a better editing paradigm. VS Code is no more competition to it than Nano or Emacs were.


Disclaimer: I'm a long-time Vim user who can't stand editing text without the modal editing paradigm anymore.

Emacs is a competition to Vim, because it has a couple things that Vim does not have:

1. It can understand that a certain part of a file is written in one language and another in another language; and then give you appropriate syntax highlighting, indentation etc. in these specific parts. Vim can't do that.

2. It is an actual GUI application as opposed to GVim which is basically a terminal with vim and a toolbar. It (Emacs) can render proportional fonts, which is really nice when you edit org/LaTeX documents.

3. Its scripting language is a lot nicer to work with.

For these reasons, whenever I can, I use Emacs with evil-mode. For the occasional editing of a file on a server or an embedded device I will still fire up vim (or vi in the latter case, since then vim will usually not be available). I encourage you to try it.


> [Emacs] can understand that a certain part of a file is written in one language and another in another language; and then give you appropriate syntax highlighting, indentation etc. in these specific parts. Vim can't do that.

Sure it can! Here[1]'s an example of someone using it for html embedded in heredocs.

> [Emacs'] scripting language is a lot nicer to work with.

This is not a fundamental limitation. E.G. neovim uses lua. (I'm not counting python and lua embedded in vim, because afaik they're a total pain to work with.)

I actually recently started transitioning from vim to emacs recently, but I don't think any of your arguments in favour of it are particularly strong. I do, however, agree that vim and emacs are at the cutting-edge of text editing, possibly along with some more niche editors like vis, sam, and kakoune.

1: https://forum.dlang.org/post/bvznmyneecpwgrxmgnby@forum.dlan...


Or PyCharm, or Eclipse, or ...

It like asking what do the cool kids code in? And happily, one prudent quora.com user answered: "Smalltalk!" [1]

[1] https://www.quora.com/Which-should-be-my-first-programming-l.... OK, not quite in my words. Also: looks like there is now a subscribe wall...


I don't know about VSC but most IDEs are rather difficult to extend. VIM makes it quite easy to create a plugin or prototype new ideas. If you don't need clever code completion etc., VIM is still very useful. Other than emacs, VIM also has some guidelines wrt to code organisation (pack, plugin, autoload, ftplugin, syntax etc.) that make things easier. vimscript is a simple language that has its warts but actually is quite useful in the context of this editor. To some extent, you can write (parts of) your plugins also in python, ruby, lua, mzscheme etc.

So, to some extent it's still useful and relevant. VIM also runs on your android phone, VSC, Idea, Eclipse etc. don't.

WRT to learning lisp, I'd recommend racket. It's scheme and unfortunately mzscheme lacks the libraries, e.g., common lisp has. It's very useful nevertheless.


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

My own experience:

- I use VSCode in Vim mode because I'm just more productive with Vim keybindings

- I use Vim for Git commit messages

- I use Vim to edit the odd file (dotfile, config...) or when I'm in a deep terminal session

- I use Vim to view/edit files on servers or local containers


Vim and Emacs have a bunch of features that you won't find on editors like VS Code. VS Code has some features you won't find on Vim and Emacs.

One of the great advantages of these "old-school" text editors is the extent to which they can be customized. This is even more true about Emacs, which is mainly written in its own "scripting" language. Almost everything on Emacs is exposed to the user during runtime. It's very easy to make both temporary and permanent changes. Emacs is self-documenting: there are handy commands to find keybindings, variables, and functions definitions. If this is not good enough, you can go straight to the source code and redefine whatever you want. You just need to evaluate the code for it to become available at runtime: no reboot necessary. Once you get used to this level of freedom, it's hard to get used to other platforms.

One thing I'd like to point out is that, even though Vim and Emacs are old, this doesn't mean they're stuck in time. They are constantly updated to support all the current technologies that people might associate with newer text editors like Atom and VS Code.


The answer to your first question is: Yes.

As you say, there are some really great editors like VS Code available these days and I have used many, if not most of them but I keep coming back to Vim. The reason is that I feel so much more productive in it. I can do things with three simple keystrokes that are quite a bit more involved in other editors. And that’s pure, stock Vim without any plugins. It’s astounding what I can accomplish with the addition of some plugins.

Really, in the end, it’s just another tool that fits me well. It may not fit you as well and that’s ok. But there is definitely still a place for old-school editors like Vim and Emacs in a modern developer’s toolkit.

As an aside; I don’t know why OP was downvoted so heavily. There is absolutely nothing wrong with asking a question such as this. I have to account for the possibility that it was edited to be less caustic by the time I read it but, if that wasn’t the case, I think all who downvoted it should re-evaluate their decision to do so. We should celebrate the desire to understand something and, from what I can see, that’s all this person is trying to do.


In my mind the main reason why Vim still has relevance today is for seat-of-your-pants SSH'ing, which admittedly shouldn't be done but it still is. Outside of that...

I still have hope for structural editing but I don't see Vim as the innovator in that space anymore.

https://www.youtube.com/watch?v=CnbVCNIh1NA


I think you should use the environment that makes you the most productive (and happiest).

For me that is vim.

But I also have the questionable (and questioned) opinion that, for that matter, you can write a state of the art program in Fortran. If you happen to find a O(n) algorithm for prime factorisation, and you write it in Fortran, would it not be state of the art?


SLIME has a successor now called Sly, but yes that's still state of the art for Lisp programming.

No, you don't have to learn emacs to get started with Lisp though. You'll just have an inferior experience.

As a side note, if you do start to learn without emacs, please use something like this[1] for formatting your code. Most editors lack a Lisp indentation plugin, and any time you ask a question online, whomever answers it will have to reformat otherwise.

1: https://github.com/ds26gte/scmindent (it's even in npm)


I don't think it's fair to call it a successor since it intentionally doesn't implement all the features of Slime.

I'm specifically talking about presentations which were removed because the author of Sly never uses them. For the first people who do, however, Sly can never be a successor to Slime.

It may be an alternative, and a pretty good one, but not enough a successor.


I didn't realize it lacks presentations, as I'm still using slime. That's good to know.


> You'll just have an inferior experience.

I detect an emacs joke here.


I use, or have used, vim bindings in vscode, visual studio on windows, etc etc.

Sometimes you run across large ascii files, e.g csv data files, and vim is the only editor that can open them.

Vim is available virtually everywhere you have a unix-resembling system, including gitbash on windows.

And sometimes you need to edit some config file in a weird environment over ssh and there’s nothing else present.

Oh, and macros can help with laborious file conversion processes. Etc.


Vim is highly customizable, the one you get on most unix systems are engines and transmission only.

The engines and transmission are incredibly powerful, the only problems is you sit on top of metal with a stick as your wheel.

But you can turn all that into a fully working luxury car/truck/whatever you like by digging in and customizing it. In the age of "don't build the wheel", you can also do that by installing component that other people have built already.


I don't think learning GNU Emacs using a window-based version would be too difficult. The obvious advantage is better tool support via SLIME for interactive Lisp development with SBCL.

Support for development with Common Lisp in Visual Studio is relatively primitive and has very little momentum - at least that's my impression.


I don't really see why you would write any lisp in an editor that isn't Emacs. Visual Studio Code is very capable... of jumping in to a hot loop periodically to crash or require you to kill it, sapping your battery at idle, and making rookie mistakes long-since corrected by the 40-year editors.

If I were looking to replace Emacs, replicating CIDER is a tall order, especially CIDER over TRAMP. Tell me when you can automatically shell into your high-memory remote machine with an editor running locally, and get a full REPL with inline evaluation on the remote machine.. and it "just works" (i.e. install the package from MELPA, and it works out of the box).


If you're running on a battery and aren't sure you'll be able to plugin in the next 10 minutes.


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.


Slimv tutorial has static screen captures to show what the Slimv experience looks like: 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.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: