Congrats on the alpha release! I've been following the jank blog for a year now and it's great to see it reach this milestone. What is the current state of development tooling (such as CIDER support) for Emacs users?

Also I noticed a typo/broken link in the Welcome section: The link for "foreward" points to https://book.jank-lang.org/foreward.html, but it should be https://book.jank-lang.org/foreword.html

We have a working nREPL server, but it's not yet merged into the jank repo. https://github.com/kylc/try-jank

There's a Clang bug getting in the way of the progress we want, so we'll need to work around. There's a lot I'm juggling, but this is high priority.

Thanks for the broken link report. That should be fixed now.

While Emacs can run in a terminal, it is more widely used as a GUI application that can render images, PDFs, variable-pitch fonts, handle mouse support (drag-and-drop, menus, scrollbars), and even work on touchscreens such as on Android [1].

You are right that VS Code has a "nicer" out of the box UX (this is subjective of course), but Emacs offers a malleable environment. In VS Code, you are limited to what the APIs the developers decided to expose. If you want a specific behavior that isn't supported, you either fork the editor or create a feature request ticket and wait for someone to prioritize it. In Emacs, because you have full access to the internal runtime, you can implement that feature yourself in a couple of lines of Lisp.

1: https://kristofferbalintona.me/posts/202505291438/

Thanks, it's been so very long since I've tried emacs. I remember I didn't like how it looked. So I used vim instead. (There was no vscode back then.) So I never did give it much of a try.

Emacs might be a solid editor choice but my intuition is that it probably won't be worth it for the same reason LiteXL wasn't for me. If I do work on adding features to my editor I think I'd be more comfortable doing it in js, html and css. And if possible I'd rather start with a base that's mostly where I want it to be. Trying to turn emacs into vscode sounds like way more of a project than turning Theia or CodeMirror into vscode.

Actually there are plenty of packages already which can near Emacs to VSC or Sublime in look and feel, and imho go circles around the 2 in functionality.

Care to link to those? I looked and all I found was this:

https://github.com/DevelopmentCool2449/visual-emacs

Which didn't really impress me terribly much.

I don’t know them, because I do not like VSC and co. I just have a friend, and when I see his Emacs looks like sublime. Is some work to get it to look like that.

This pivot sounds like VS Code is moving from a text editor to a thin client for AI services that Microsoft wants to push. It is one more step towards a future where our development tools (just like everything else on our computers these days) are just thin clients/wrappers around SaaS.

Emacs remains the antidote to this. I use Emacs because I want to remain the architect of my development environment, not become the consumer of a telemetry-gathering platform architected by PMs at a big tech company. It is also an absolute joy to use an environment that provides you with the same amount of power as the core maintainers, allowing you to fully inspect and modify the system even while it is running.

My path in the emacs/vi divide forked a lifetime ago, and emacs is so fundamentally different that it was never worth sacrificing the massive productivity vim gives me to dip back into emacs

But maybe that should change. I like vscode for when I need more IDE features than I care to cobble together with plugins.

I don’t need another subscription in my life. Especially for anything I rely on.

I was more familiar with Vim bindings and relied on Vim emulation layers in various IDEs before I moved to Emacs. Evil mode and Doom made the jump possible without sacrificing too much productivity. With Evil, I didn't have to retrain my muscle memory and with Doom I didn't have to cobble together a functional config from scratch.

After a couple of months of using Doom, I felt comfortable enough to roll my own config which also helped me better understand how things worked at a lower level. More interestingly, after a couple of years, I transitioned from Evil to standard Emacs bindings as that felt better integrated with the rest of Emacs.

My path was similar, except with Spacemacs, which has excellent Vim-like modal key bindings. I've been using a custom config for many years now, but evil-mode has been a crucial part of my setup. A modal interface is simply easier to use and more intuitive than twisting your fingers to hit complex key chords. I use Vi mode in shells, TUI programs, REPLs, anywhere Readline is supported, etc.

So Emacs+Vim is the best of both worlds. You get the infinite extensibility of Emacs and a sane(-ish) programming language, with the superior editing and command interface. The beauty of Emacs is that it really doesn't matter how you use it. For some modes you may need to override a keymap, or use a package like evil-collection, but most behave well OOB IME.