Lisp Programming in Vim with Slimv or Vlime
susam.in
susam.in
A previous article on using Fennel for lispy Neovim configuration was posted here a week ago [1].
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.
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.
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.
- 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.
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?
I still have hope for structural editing but I don't see Vim as the innovator in that space anymore.
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.
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
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.
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...
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.
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...
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.
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?
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.
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.
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.
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'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 detect an emacs joke here.
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.
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.
Support for development with Common Lisp in Visual Studio is relatively primitive and has very little momentum - at least that's my impression.
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).
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.
Vlime README has a terminal session recording that provides a quick demo of the plugin: https://github.com/l04m33/vlime#readme.