4 ms·
God a neomacs written in a faster, more modern lisp would be a dream.
by sooheon 10y ago
God a neomacs written in a faster, more modern lisp would be a dream.
- bryanlarsen 10y agoIt's called guile emacs. https://lwn.net/Articles/615220/ https://lwn.net/Articles/615220/ https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
- fatbird 10y agoInteresting. Any idea on why it's not got more traction? Or is it actually on track to become the canonical emacs? Reading that LWN article, it looks like Guile wasn't a great choice from a community perspective, but more than that, by working internally to the emacs project it's subjected itself to internal standards of interoperability that it'll never really be able to hit (where a pseudo-hostile fork like xEmacs was might have sufficient momentum to force some accommodation).
- qwertyuiop924 10y agoIt sorta works, but it's hard to keep it working, so people don't really do much with it. Shockingly, the compatability was pretty good, last I checked. If you really want an emacs written in a sane Lisp, and don't mind losing gnuemacs compatability, check out Hemlock. or Edwin.
- draven 10y ago> check out Hemlock. or Edwin. Or Climacs https://www.common-lisp.net/project/climacs/ https://www.common-lisp.net/project/climacs/ It seems there's a rewrite as well: https://github.com/robert-strandh/Second-Climacs https://github.com/robert-strandh/Second-Climacs
- qwertyuiop924 10y agoOh. I forgot Climacs. Well, there you go. Another CL editor.
- lispm 10y agoHere is another one: https://github.com/cxxxr/lem https://github.com/cxxxr/lem
- sedachv 10y ago> Reading that LWN article, it looks like Guile wasn't a great choice from a community perspective I think going forward it will be. Between Guile-Emacs, Guix, and GNU Shepherd you have the best-supported Lisp Machine operating system analogue available right now: https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/ I am excited about GuixSD and I think a lot of other people will be.
- armitron 10y agoNo it wont, at least as far as Emacs is concerned. Nobody is stepping up to do the work, plus Guile has serious bugs on Windows and OSX, single-digit number of developers and few, if any, users. So Guile Emacs is really a pipe dream that people like to bring up from time to time.
- sedachv 10y ago> Nobody is stepping up to do the work, plus Guile has serious bugs on Windows and OSX, single-digit number of developers and few, if any, users. So Guile Emacs is really a pipe dream that people like to bring up from time to time. You forgot to mention that BSD is dying. This state of affairs is different from any other Lisp implementation how? And why would it stop progress from being made?
- armitron 10y agoI've been happily running SBCL and CCL on Linux and OSX for years without issues. CCL on Windows too. Guile has 1-2 people working on it part-time, and Windows/OSX are not a priority because: + GNU project, duh. + Nobody in Guile-land cares about Windows/OSX enough to step up and fix issues. + Even if they did, Stallman would tell them not to. So the state of affairs is indeed very different from the CL Lisp implementations. Not to mention, Guile has pretty much no userbase to speak of. There are commercial entities releasing products with SBCL and CCL in addition to the very healthy opensource community.
- lispm 10y ago> best-supported Lisp Machine operating system analogue Hardly. GNU is far from anything Lisp Machine. The Lisp Machine was never a system hacked up by scripts running on top of some Unix copy with a fancy name.
- AceJohnny2 10y agoGuile Emacs isn't a bottom-up rewrite of Emacs [1], but a project to replace the elisp runtime with Guile. One important thing it does not do is get rid of/convert any ELisp, because of how much is invested in it: 71% of the ~2M LOC codebase is ELisp: https://www.openhub.net/p/emacs https://www.openhub.net/p/emacs Guile would run the ELisp code. What's holding the project back, IIRC, is that it doesn't yet do so perfectly. [1] which is something I (and likely most users) frequently think it sorely needs, until we realize A) the monumental size of the task and B) how much refinement the current version already has, as per http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- zeveb 10y agoAs I note elsethread, Guile Scheme is not a 'faster, more modern Lisp,' because Scheme is not Lisp. Scheme is a Lisp-like language, which does have a place in the world, but it's not Lisp, and it's not (IMHO) well-suited for large software projects like emacs. I personally oppose a Scheme-based emacs because, having moved from C to a more Lisp-like language, I don't think there would be the will to actually move to real Lisp. You might accuse me of letting the best be the enemy of the good (which is a fair criticism, both of my position re. porting emacs & of Zaretskii's re. the dumper), but part of why I use emacs and Lisp is that they are not good: they are the best.
- loup-vaillant 10y agoEmacs-Lisp is dynamically scoped. That's precisely the kind of mistake (yes, mistake), that hinders large scale anything. And who cares Scheme is not Lisp? It's close, and it's reputedly cleaner. Besides, there are many Lisp dialects, some of them just as different from one another than Scheme is from them.
- zeveb 10y ago> Emacs-Lisp is dynamically scoped. That's precisely the kind of mistake (yes, mistake), that hinders large scale anything. Yup, default-dynamic scope is a mistake, although in the particular case of emacs it has made certain code very clean (and led to plenty of bugs, as well). Emacs has added lexical scoping, which is a start. Common Lisp's lexical default and optional dynamic scoping provides the best of both worlds. > And who cares Scheme is not Lisp? It's close, and it's reputedly cleaner. Among other things, its continuations are semantically broken, preventing correct implementation of UNWIND-PROTECT. It's a good language for its intended purpose (teaching & research), but the language as standarised is not well-suited for building large projects (individual implementations, of course, can be quite good — but then one enters the world of implementation-dependence). Common Lisp is superior for large projects, in part because it's much more fully-specified, in part because that specification includes more features, in part culturally (because Lisp systems have more often tended to be large and long-lasting).