Huh, I wonder why they made their own IDE instead of integrating with Sly/SLIME. Not trying to knock the project, just genuinely curious. Writing a whole editor sounds like a lot of work.
I like the choice of Iosevka as a font, though.
Edit: One value I do see myself getting from Mine is as an example Coalton project. Last time I tried Coalton I couldn't figure out how to get ASDF to load standalone Coalton files. Now I have a working example to copy.
There is an explanation in the blog: https://coalton-lang.github.io/20260424-mine/
> However, the above is a tall order for someone just wanting to dip their toes in, to see if they have any interest in Coalton or Common Lisp. A couple hours on the weekend is easily sunk into getting configurations right, and the right subsystems installed, and the right paths setup, just so the first line of code can be executed.
> mine is not Emacs. It aims to eliminate all of that, and be a Coalton/Lisp-first development environment, whose only job is to be a Coalton/Lisp-first development environment. But more than that, it needs to be accessible. A non-programmer should find it easy to download, install, and run mine with nothing more than a download link.
> mine is not Emacs.
Ah… yes, okay, I see what they did there… chuckle, sigh. Well, it's arguably in the same grand cultural tradition as EINE and ZWEI at least!
I vaguely remember that there was also TRES. EINE = Eine Is Not Emacs
ZWEI = Zwei Was Eine Initially
TRES = Tres Replaces Eine’s Successor
DREI = DREI Replaces EINE's Inheritor
https://mcclim.common-lisp.dev/static/documents/drei.pdf
Why would a non-programmer want to download, install and run a CL IDE?
1. It is a potential first step on the way from non-programmer to programmer.
2. "Easy enough for a non-programmer" may also say something about how easy it is for a programmer.
I think the number of non-programmers who think 'I want to learn to program; I'll start with common lisp but emacs is too difficult!' is so small it is not a group worth considering. It's probably MIT & Stanford undergrads?
It's their IDE and they can design it how they want, but that's a weird goal for a CL IDE.
You haven't seen the Lisp subreddit then, there is a post complaining about having to learn Emacs at least once every week or so.
I personally suspect that the overwhelming majority of those complaining would find a different reason to not learn lisp if the Emacs barrier were removed, but I very much might be wrong.
Coalton is also a full-featured embedded language of Lisp that is sufficiently paradigmatically different than run-of-the-mill Lisp code you'd see in a Common Lisp textbook, since it has a complete, Haskell-like static type system and Lisp-1 naming. Coalton also sees active development because aspects of the language continue to evolve.
The consequence is that an integration with SLIME would have to be a very extensive contrib [1] that is shipped with the Coalton version the user is using, and updated whenever Coalton is updated. No doubt the contrib would have to be very elaborate—it would have to hook in to basically every aspect of SLIME and SWANK if it should be "Coalton-native", from the display of type errors to how auto-complete is handled. Unless the contrib author is very meticulous about backward compatibility, then version mismatches would make everyone involved unhappy. The contrib author would get annoyed at constant bug reports about things not working (even if there's a nice "your Coalton or contrib are out-of-date" error), and users would get annoyed they have to keep a Lisp library in sync with an Emacs add-on.
None of this gets to the matter that Emacs simply isn't a popular text editor, and it's not really the one people are rushing to learn, even if it has substantial merit. I don't know how trustworthy this source is [2], but it claims that Emacs represents a fraction of a percent of the developer community. Even if it's off by 10x, it's still 1-in-50 developers at best.
[1] There's a basic one that shows Coalton type hints, but not much more: https://github.com/slime/slime/blob/master/contrib/slime-coa...
[2] https://pypl.github.io/IDE.html
Iosevka is the king of scalable terminal/programming fonts. I'm not sure why, maybe it's because the glyphs have lines and angles that look "terminal-y" in the same pleasing way Terminus and the 3270 font do whilst avoiding the problems that accompany trying to scale a pixel font.
I love Iosevka. I use it as my monospace, serif and sans-serif fonts and it's gorgeous, in its own unique way.