It is missing most useful Emacs features but also seems to have some of it's own, particularly for CL.
- 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)"'
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.
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)
You're not only more than a vim user, you don't even use vim!
Your problem with Vim is that you don't grok vi
https://stackoverflow.com/questions/72498282/your-problem-wi...
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
Maybe Einstein used LaTeX ( ͡° ͜ʖ ͡°)
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)
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).
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:
I think someone should lock down emacs+slime, add some goodies, change keybindings and call it an IDE.
Also, lem (already mentioned elsewhere in this thread)
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.
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.
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...
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 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.
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.