I was recently reading the vi (not vim) manual page and found this note under “SET OPTIONS”:
Vi only. Modify various search commands and options to work
with Lisp. This option is not yet implemented.
I don’t know if this is just a nvi thing, or if such a feature was generally never implemented. It would certainly be interesting to see what these “modifications” would be. Something like paredit or just changing the definition of words to lisp symbols…
But related to this article, is there anything one does better with lisp for vim? Would you recommend it to a beginner in lisp with no editing experience/preference? I’ve always just used Emacs, and ironically never had a perfect lisp setup, but then again I also can’t compare.
Interesting! FWIW, Vim does have set lisp:
While most lispers seem to use Emacs, Vi is by no means rare. I remember reading that Paul Graham uses some sort of Vi. And I use Vim, to the extent that I can be considered a lisper.
Another example is the author of Let over Lambda, Doug Hoyte, who explains why he uses vi in said book. Then again, because they were writing 15-25 years ago, their story is a totally different one from the slimv and vlime usage explained in this article.
I’m using Clojure(Script) for the first time in a side-project for a simple website to interact with an API. I’m a Vim user but I’m sort of lost in between:
I’m used to just setting up a language-server for a language and more or less going on from there. So far I really likeeraserhd/parinfer-rust and snoe/clojure-lsp but it seems like I’m missing out on other things? I realise that some of the above overlap/call each other. I suppose that some of my uncertainty comes from being new to Lisp and how the development flow works a little bit different to other languages?
This article uses the original author’s Vlime repository at http://github.com/l04m33/vlime which hasn’t been updated in a few years (of course, it still works okay, since Common Lisp and Vim are generally pretty good about backwards compatibility, unlike most languages/environments).
A while back I contacted the author and they said they had no plans to continue work, and were fine with other people taking over maintenance. A couple of months ago, Philipp Marek, Eitaro Fukamachi, and I set up https://github.com/vlime/vlime to track the changes we’ve been making. So if you encounter bugs or want more features out of Vlime, you might consider trying that new repository. I don’t think any further development will be happening at the old one.