Hacker News Reader

Comment by b3lm0nt | Hacker News Reader

I wanted to love Common Lisp, but as a Vim user every day was a struggle. One typically uses plugins (Slimv, Vlime) that contort buffers in bizarre ways in order to simulate the SLIME EMacs REPL — if not, they will lose out on the interactive development experience that is so central to CL.

Being tied to either EMacs or an enterprise solution like LispWorks to get the full language experience was ultimately a non-starter. I’d love for someone to build an alternative CL development experience that could work in a wider range of text editors and IDEs.

There is a lot to learn from CL, but I think it can be hard to access for most developers.

View on HN

A flavour of emacs called 'doom emacs' is basically emacs for vim users (same keybindings and many similar features): https://github.com/doomemacs/doomemacs?tab=readme-ov-file#do...

Great set of instructions for how to set it up here: https://www.youtube.com/watch?v=xyXDE5gP2QI

(and if you're on macOS, this video is flawless for installation specifics: https://www.youtube.com/watch?v=A6SxH9lUWV0)

As a vim user, I’ve been using doom emacs for the past 3.5 years and haven’t looked back yet. I really enjoy the Common Lisp experience while using doom as well.

I should also note that I’m looking forward to CLOG being ready as an in-browser IDE for Common Lisp soon. It’s a really neat open source tool for developers if you haven’t heard of it yet: https://github.com/rabbibotton/clog

I use it everyday for all my Lisp dev :) So is ready.

I appreciate the message you're conveying (I also switched from using vim for years to emacs for years, probably for good) but man, we have to stop attaching tools to our identities.

You're not only more than a vim user, you don't even use vim!

I would argue Evil mode (which Doom Emacs includes) is an implementation on Vim. Only instead of being an implementation in C, it's an implementation in Elisp.

I equate Vim not with the weird configuration language or source code of the original Vim project, but with the interaction language it uses – and Evil uses the same one.

Evil is more than "a vim compatibility layer" -- it is a reimplementation of Vim closer in spirit to nvim than anything else.

Some tools are closer to being identities than others. Being a 'vim user' is more like being a Dvorak user, it lives in muscle memory. 'vim user' is overloaded here, it colloquially means "user of the vim text editing language" rather than (just) "user of the text editor, vim".

I'm about intermediate at wielding vim, and the VSCode plugin implements enough of the language for me. But I'm fluent enough that being deprived of it is unpleasant, and I won't willingly edit text using a program which doesn't implement a decent vim mode.

It's not like computer languages or applications: the right number of text editing command-languages to be good at, like the right number of keyboard layouts, is one. Typing on a keyboard, and editing text, is my job. I don't want to waste time and productivity on learning several ways to do it, these are means to an end.

This being HN, someone might come up with some valid reasons to master more than one keyboard layout, particularly a "weird" one while retaining fluency in a standard one. Granted, call it a concession to an imperfect world.

Funnily enough the main keyboard I use is a split, columnar, Dvorak board. I also use a lot of tools that people like to attach to their identity: SwayWM (tiling wm user), Lisp and Scheme (Lisper and Schemer), GNU/Linux... I do not see these at all as a part of my identity. I think making these a part of my creates an aversion to change, and therefore progress.

Historically I have even used distros that people heavily identify with and call "end game distros", like Arch Linux, Gentoo, and NixOS. The former two I used for years each. I eventually have landed on GNU Guix, since for me it has worked better than anything else I've tried for my needs.

I really mean it when I say we should identify with our tools less. You may consciously identify with tools that you want to solidify as a part of yourself even with the potential aversion to progress which that may include. I can't think of any tools I would do that for though.

Stop being vim-purist! There are so many ways that one can be a vim user, and yes, using vim is not necessary

What is necessary to be a vim user?

> What is necessary to be a vim user?

Think of vim-navigation as an idea without conceptual attachment to any concrete editor. Vim-navigation can be used even without any editor at all. Some people (like me) use vim-navigation in their browsers, terminals and their WMs. I control my music, windows, apps, etc., with h/j/k/l. My Neovim config is minimal because I rarely use it. Yet in Emacs, I use it extensively. Perhaps even more broadly than when I wasn't an Emacs user.

When people say "I'm a Vim user," they usually mean the concrete editor Vim/Gvim/Neovim because it is really difficult to replicate Vim outside of Vim. Every single plugin, editor, or IDE is just an emulation, with rare exceptions like Helix (which from the get-go was designed to have good support for it) and Emacs, which, due to its nature of being malleable and super-hackable, allows very nice integration of Vim features. Seasoned vimmers know that there's pretty much no vimming unless you're using Vim/Neovim https://x.com/garybernhardt/status/902956444596617216?lang=e... The caveat there is that they never tried Emacs with Evil. Evil is surprisingly very good. Probably the best implementation of vim.

And when you combine these two ideas - Vim navigation and Lisp, you get something truly amazing. Anyone who fervently detests one concrete implementation in favor of the other probably has a shallow understanding of either of these ideas. Write enough Lisp, and instead of getting angry at people trying to "vimify" your beloved Emacs, you'd be saying: "Cool, another testament to how awesome Emacs and Lisp are..."; learn enough Vim, and you would want to have it everywhere, not just in your favorite editor.

It's about modal editing and the editing commands/paradigm inherent in that.

This is a classic explanation:

Your problem with Vim is that you don't grok vi

https://stackoverflow.com/questions/72498282/your-problem-wi...

Direct link to original SE posting: https://stackoverflow.com/questions/1218390/what-is-your-mos...

Better, thanks.

Common Lisp in Doom uses Sly. If you want to stick to Slime and prefer vim ergonomics to those of Emacs there is also Spacemacs, which I just learned even has its own Wikipedia page: https://en.m.wikipedia.org/wiki/Spacemacs

That sort of thing is all configurable. It's easy to tell Doom Emacs to use Slime instead.

More editor plugins have been developed in the recent years: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Atom/Pulsar (very good support), VSCode (good, in development), Sublime, Jetbrains suite, Jupyter notebooks…

And that's not all. Lem, a general-purpose editor tailored for CL (see other comments below),

and even more recent, the CLOG builder (CL Omnificient GUI) which ships an editor in the browser: https://github.com/rabbibotton/clog-linux-ez/releases/ && https://github.com/rabbibotton/clog-win64-ez/releases

Rustaceans could help on this project: https://github.com/fonol/parrot/ (Rust, Tauri)

Indeed! Some time ago, I've made this video review of 8 (EIGHT!) IDE to work with Common Lisp:

https://www.youtube.com/watch?v=eTgDaMREKT4&t=2s

Take a time and choose one. The world is not limited only by Vim and Emacs. However, I prefer emacs these days (happily switched from Vim a decade ago).

The author of “Let Over Lambda” dislikes Emacs and does not use it. What’s more, he didn’t use Slimv or anything like it or even Vim at all. He used a more basic vi, maybe nvi.

So perhaps the interactive experience is not essential. You can just edit and compile like you would in C. That’s not what I do—-I use Slime—but it is possible. Also, a lot of the interactivity is required by the standard to be built in to your Lisp’s REPL, so you can do quite a bit if your REPL isn’t primitive. SBCL doesn’t even have readline but you can use rlwrap.

https://letoverlambda.com/

> The author of “Let Over Lambda” dislikes Emacs and does not use it.

I have no idea what Hoyte like to type in, but why does it matter what text editor he uses? Einstein didn't had any computer, not even a calculator. Do we have to use paper and pencil for all the calculations just because Einstein did? Our physics teacher in gymnasium, forced us for 4 years to do all calculations on tests by hand, at four decimal places, with that exact excuse: Einstein didn't have a mini calc. Non of us have become a Nobel prize taker in physics :).

> Also, a lot of the interactivity is required by the standard to be built in to your Lisp’s REPL, so you can do quite a bit if your REPL isn’t primitive.

Mnjah; not so much really. Using at least SBCL from plain command line really sucks. If you mistype something you have to retype everything, no history, etc.

> SBCL doesn’t even have readline

If you are on some *nix OS, you can get a long way by just using SBCL with built-in sb-aclrepl + linedit. Aclrepl gives you "command-like" stuff, similar to ":" in Vi (or M-x in Emacs), and linedit adds cursor motion, history and some basic completion. I would still not type entire programs in repl, but for running and testing the code it is a basic survival kit. For me personally it is enough.

There is also cl-repl package which gives you native bindings and some extras if you want to go all-in readline from within the lisp itself.

> Einstein didn't had any computer, not even a calculator.

Maybe Einstein used LaTeX ( ͡° ͜ʖ ͡°)

"Lem is the editor/IDE well-tuned for Common Lisp. [...] If you come from Emacs or Vim, you will feel right at home."

https://lem-project.github.io/

I'm curious, how does Lem compare to Emacs as a common lisp ide?

It compares pretty well: it has all the essential features, and some more. It only lacks a couple keybindings in my eyes (shortcut to call the function at point in the REPL, shortcut to "change-package" from a lisp file). It has:

- the interactive debugger

- the Lisp REPL

  - so we can have a full-featured Lisp REPL on the terminal with: alias ilem='lem --eval "(lem-lisp-mode:start-lisp-repl t)"'

- the same compilation, evaluation, code navigation keybindings and error reporting

some more:

- when we evaluate an expression, it will show a loading spinner during that time and then the result in an overlay.

- a "watch" command that shows results in the overlay too https://lem-project.github.io/usage/common_lisp/#watch

Overall, Lem has:

- a built-in LSP client that is known to work with other languages (and syntax highlighting for many languages)

- some tools, still more rudimentary than Emacs: directory mode, find file in project, project tree side view, Git tool (shows status, does interactive rebase)…

- it is in the process of having co-editing in Lem itself. The developer(s) are beta-testing a collaborative web-based version of Lem: https://github.com/sponsors/cxxxr

Lem has ncurses and SDL2 interfaces.

https://lem-project.github.io/usage/usage/

It's pretty raw and buggy still, but if you're already a cl hacker, you'll certainly enjoy it.

It is missing most useful Emacs features but also seems to have some of it's own, particularly for CL.

I just do it in vim and tmux (it used to be screen):

https://blog.djhaskin.com/blog/developing-common-lisp-using-...

This works real well. I honestly don't see the point of slime, it feels like it was written so that people didn't have to use the terminal, but the terminal works just fine for me.

I even wrote a :make plugin for it, which works well enough:

https://git.sr.ht/~skin/roswell-sbcl.vim

Understandable, but it also seems like there is a disconnect between the philosophy of vi and the philosophy of Lisp. Vi is designed to be purely a text editor, and not an environment for building text based applications. Common Lisp being so inherently interactive, seems to require a dynamic, interactive text editing environment. Like Emacs.

Hmm, IIRC Paul Graham also used vi most of his coding years. So yes, great things can be accomplished with vi in the Lisp galaxy.

But that is old. Vim can easily interact with lisp real time. It would and probably never will be the same as emacs which is a lisp env. Still it is good enough.

GNU Emacs nor XEmacs also can not behave like ZMACS on lisp machines - there's just as much disconnect as between (n)ViM and lisp image. It's always a remote, RPC-like relation.

In fact, I'd say that a certain ancient Erlang mode for Emacs resulted in closer relationship between Emacs and Erlang, as it made Emacs into a process in OTP cluster.

There's also an interesting SWI-Prolog mode that embeds the language runtime with dynamic linking and integrates quite deeply.

Back in my CL days I loved Slimv. It had its warts, but was miles beyond having a shell with a REPL open. I imagine it has only gotten better since (I haven't touched lisp in almost 10 years now). That said, I never gave Emacs a serious shake so I was probably missing out quite a lot on what a good interactive experience could be.

If you use Neovim, you could try Conjure.

I really like it for other lisps, but I haven’t used it for Common Lisp. I wouldn’t say it “contorts buffers in a bizarre way,” although in my experience, different Vim users have their own take on that.

I would be very interested to read about the limits of conjure. In my mind it is a fabulous tool, with vim-sexp it is very productive to write clojure code with and a pleasure to use.

I had similar issues trying to get used to EMACS when I was playing the CL. Add to that the fact that I tend to use Windows at least half of the time, and I wanted an alternative.

I ended up setting up Atom with SLIMA and some other plugins to do CL development on Windows and Ubuntu. I even wrote up some very sparse instructions https://github.com/Kehvarl/roguelike-tutorial-cl/blob/main/d...

While Atom is gone, Pulsar now has a SLIMA plugin to allow Lisp interaction.

I don't understand. Why not just use Emacs with evil-mode?

> Why not just use Emacs

Emacs is an ethereal substance. You cannot "use" it. Just like with magic - there are no users of Emacs, you can be skilled practitioner or a beginner but you don't "use" magic - you apply it to create or to destroy. To slay dragons, to amaze and terrify uninitiated ones

https://twitter.com/iLemming/status/1093349152199630848

Seriously though, Emacs is hard. Especially these days, when the constant flow of distractions is intense. People these days do not have the patience for learning anything that takes them longer than an hour to grok. They'd rather duct tape things with "left-pad" solutions and call it "it just works"™, and if [insert fav editor here] doesn't support something, they lose any incentive to even try things.

Ok, I get that from someone coming from vscode but Vim certainly takes more than one hour to grok.

My point is Emacs+evil-mode is close to indistinguishable from Vim. I know this because I come from Vim.

I think @reddit_clone hit the nail on the head. It is just an irrational adverse reaction to hearing the word Emacs.

I think I should've tried better to emphasize sarcasm. Emacs is an incredibly powerful tool. And honestly, I don't understand people who try to learn it only to complain shortly after how hard it is compared to VSCode, and they don't want to "waste their time." Dude, you chose to be in this field. A text editor is a single, the most important, the most consequential tool of your professional lifetime of a programmer. LIFETIME!!! Why the heck not spend some of that time learning it?

Cause some of us want to write code instead of screw around endlessly configuring a text editor?

You still need to tinker all the time - that's part of our jobs. You need to configure and use various tools, for note-taking, Zettelcasten, GTD, TODOs, Pomodoro, Habits, Anki-Cards, etc. You need to tinker with your terminal, write various scripts, in awk, bash, perl, python, etc. You need to manage your Postman collections, nix files, dotfiles, PDF annotations, gpg and ssh keys, shell history, browser history, browser settings, git settings, package management, jupyter notebooks, etc.

Now, Imagine if you could really learn just a single tool that could help you manage all that—one integrated environment where you can take notes, organize tasks, manage your schedule, write code and annotations, write scientific papers, automate workflows, handle version control and secure communications. Some versatile, extensible, and powerful editor that can be customized to fit all your needs, where you turn endless tinkering into a streamlined, cohesive experience, making productivity feel natural and effortless. Where if you embraced it, you'd discover how it can transform your workflow into a harmonious symphony of efficiency.

That tool does exists, but of course, why would you screw around it endlessly? After all, you have to write code instead...

Couldn't resist, since it is relevant and analogous:

https://news.ycombinator.com/item?id=34333276

I don't know either. Some people just don't like to hear 'emacs' and react negatively.

I think someone should lock down emacs+slime, add some goodies, change keybindings and call it an IDE.

Someone did: https://portacle.github.io/

Also, lem (already mentioned elsewhere in this thread)

i agree and went through the same struggles before totally giving up, i discovered racket along way tho so it was a net win

You should give common lisp another chance and see what you have been missing in racket.

i dont want to learn emacs

Emacs is essentially a Lisp-machine. Yes, I understand that this deviates from the traditional notion of a "Lisp-machine" since it's not hardware-based; nonetheless, it still fits the bill.

If you're eager to learn Lisp (not just Common Lisp, but any dialect), why not take advantage of a Lisp machine for that purpose? When you say, "I don't want to learn Emacs," you're basically saying, "I don't want to learn Lisp." You need to know Lisp to grok Emacs, you need to write it, you need to embrace it; otherwise, you're not using Emacs, you're just a passenger.

you don't have to if you don't want to. even without emacs common lisp is a better experience than racket

i wrote several projects in CL and overall disagree. and thats ok!

i prefer rackets batteries-included and library system, nice local docs, ide from this century (albeit basic editing capabilities) compilation options etc for my personal projects

i certainly understand the appeal of cl and even use lispworks in embedded work. but some tools have better ergo for me depending on time/effort/whatever

Given that you said you had lots of friction with the IDE (equating development in Common Lisp with using Emacs) I'm curious what Common Lisp projects you managed to complete in that state. I also use Racket, and I think it is a fine language, but for my use cases it doesn't really come close to the experience with Common Lisp. Still, alot of interesting projects in that community. Also, curiously, previously said you totally gave up on Common Lisp, but now you say that you use Lispworks, and for embedded of all things. How interesting! Would love it if you shared what you do.

> I also use Racket, and I think it is a fine language, but for my use cases it doesn't really come close to the experience with Common Lisp.

You mentioned in another comment that you use CL to prototype low-level computations. I assume that this is the use case that you are referring to.

Do you mind sharing why CL works better than Racket for prototyping in this domain?

Or do you have another use case for which Racket is less fit than the one I understand?

One thing I can do in Common Lisp which I can't do (almost) anywhere else (but including Racket) is proper REPL-based interactive development. Specifically, I can update state without needing to recompile my program. For my use case this is unmatched for prototyping.

As regards low-level stuff, this is very implementation specific (which is OK for low-level programming). Specifically, SBCL allows me to write much faster code than Racket. Particularly there does not need to be a speed cap or even penalty for using a high level language.

Yeah, I read this article with interest up until I got to the part where he admits you're gonna have to use either vim or emacs. I have no desire to subject myself to the pain of either of those editors, so I guess CL isn't for me.

Reply on news.ycombinator.com