5 ms·

That's already been done. More than once, in fact. The problem is that, although there are perfectly serviceable Emacsen written in Common Lisp, none of them ar

That's already been done. More than once, in fact. The problem is that, although there are perfectly serviceable Emacsen written in Common Lisp, none of them are GNU Emacs. For example, there's Hemlock from CMUCL, and its descendants built into Lispworks and Clozure Common Lisp. Those implementations aren't likely to work well as a substitute for GNU Emacs. For one thing, there's a substantial ecosystem of software that depends on specific APIs and other characteristics of GNU Emacs. Writing code to bridge GNU Emacs APIs with those available in the Hemlock descendants would be a lot of work. There are some other obstacles as well. CCL's implementation of Hemlock uses the Cocoa text architecture, so it's not portable to platforms other than macOS. The Lispworks implementation is portable across Windows and numerous UNIXEN, but the Lispworks license will not allow delivery of a proper substitute for GNU Emacs (it forbids building an application that can be construed as a Lisp development system, and when I pressed them about exactly what limits that policy implies, they explicitly used Emacs as an example of an application that would be forbidden). The original CMUCL Hemlock and its portable version are designed to work with CLX. It could probably be made to work in a modern X environment, but making it fit well into modern GUI environments and porting it to all the platforms GNU Emacs works on would be a huge amount of work. I'm probably overlooking some other Emacsen, but I don't know of any off the top of my head for which the situation is any easier.

metroholografix 6y ago
It hasn't already been done, no. The Emacs variants you mentioned (that IMV should not be referred to as "Emacs") are from-scratch new implementations of just the concept behind Emacs, but not GNU Emacs itself. They are not compatible with GNU Emacs, they don't even support a small fraction of GNU Emacs features, and are thus doomed to obsolescence / non-existent market share. So far, nobody -that I know of- has tried to move GNU Emacs to Common Lisp. GNU Emacs is a well-known, well-used platform and moving to Common Lisp could very well be worth the upfront costs. Wishful thinking aside, the GNU Emacs development community has hunkered down behind Emacs Lisp, so improving it will bring immediate and tangible benefits to every GNU Emacs user. I love Common Lisp and do use SBCL for a lot of personal projects, but I also love GNU Emacs and I will take any improvements there that I can get. Watching Emacs Lisp become a more viable general purpose language (improved performance means an expanded set of problems that it can now address) is a great development. Stefan Monnier on emacs-devel: The main benefit of such a compiler is not to run existing Elisp code faster (99% of existing Elisp code runs fast enough that the user won't notice if it runs faster) but to make it practical to write other Elisp code which would otherwise be too slow. But for that to work well, you want the new compiler to be available "everywhere", rather than just on some platforms. So it will only start being useful when it works on GNU/Linux, macOS, Windows, ARM, RISC-V, x86, amd64, MIPS, younameit (AFAIK lbgccjit's CPU coverage is already good enough for that, so the main barrier here is the OS support), and when it's not just an option at compile-time but when it's included in all builds.
- mikelevins 6y ago
  You appear to consider "Emacs" and "GNU Emacs" synonymous. I explicitly do not. Hemlock is not a reimplementation of GNU Emacs; it's derived from earlier Emacsen, just as GNU Emacs is. Hemlock in particular is based on ZWEI, and was in version 0.99 around the time that work started on the GNU Emacs project. It's a slightly older sibling of GNU Emacs, rather than a descendant of it. GNU Emacs has undoubtedly become the de facto standard Emacs, but I don't see why that disqualifies other branches of the Emacs family tree from using the name that all of them inherit from the venerable TECO implementation. My point was that Emacsen have already been built in Common Lisp, but that they do not serve as substitutes for GNU Emacs--a point with which you appear to agree. Maybe we even agree on the reason why: because no Emacs implementation can substitute for GNU Emacs without supporting its ecosystem. The amount of work needed to do that would be enormous, whether the proposed substitute is written in Common Lisp or in something else.
  - metroholografix 6y ago
    Sure, I just wanted to clarify and make it very clear that GNU Emacs in CL hasn't even been attempted since that was what the poster you originally replied to, equated "Emacs" with. As you said, the value lies primarily in the ecosystem. Common Lisp is by far the better language, but GNU Emacs is by far the most empowering/practical environment. I don't think enormous work would be needed, there are plenty of powerful shortcuts one could take (some ideas are in this thread) and Emacs Lisp can be made to run on top of Common Lisp but it's safe to say that for whatever reasons the will/intent is simply not there. Emacs Lisp is what we have to go on with and it's nice to see that it is not stagnating.
fiddlerwoaroof 6y ago
Robert Strandh is working on an Common Lisp emacs based on McClim but, McClim basically forces you to use linux.
- fiddlerwoaroof 6y ago
  There's also lem, which is more portable: https://github.com/cxxxr/lem https://github.com/cxxxr/lem

metroholografix 6y ago

It hasn't already been done, no. The Emacs variants you mentioned (that IMV should not be referred to as "Emacs") are from-scratch new implementations of just the concept behind Emacs, but not GNU Emacs itself. They are not compatible with GNU Emacs, they don't even support a small fraction of GNU Emacs features, and are thus doomed to obsolescence / non-existent market share. So far, nobody -that I know of- has tried to move GNU Emacs to Common Lisp. GNU Emacs is a well-known, well-used platform and moving to Common Lisp could very well be worth the upfront costs. Wishful thinking aside, the GNU Emacs development community has hunkered down behind Emacs Lisp, so improving it will bring immediate and tangible benefits to every GNU Emacs user. I love Common Lisp and do use SBCL for a lot of personal projects, but I also love GNU Emacs and I will take any improvements there that I can get. Watching Emacs Lisp become a more viable general purpose language (improved performance means an expanded set of problems that it can now address) is a great development. Stefan Monnier on emacs-devel: The main benefit of such a compiler is not to run existing Elisp code faster (99% of existing Elisp code runs fast enough that the user won't notice if it runs faster) but to make it practical to write other Elisp code which would otherwise be too slow. But for that to work well, you want the new compiler to be available "everywhere", rather than just on some platforms. So it will only start being useful when it works on GNU/Linux, macOS, Windows, ARM, RISC-V, x86, amd64, MIPS, younameit (AFAIK lbgccjit's CPU coverage is already good enough for that, so the main barrier here is the OS support), and when it's not just an option at compile-time but when it's included in all builds.

mikelevins 6y ago
You appear to consider "Emacs" and "GNU Emacs" synonymous. I explicitly do not. Hemlock is not a reimplementation of GNU Emacs; it's derived from earlier Emacsen, just as GNU Emacs is. Hemlock in particular is based on ZWEI, and was in version 0.99 around the time that work started on the GNU Emacs project. It's a slightly older sibling of GNU Emacs, rather than a descendant of it. GNU Emacs has undoubtedly become the de facto standard Emacs, but I don't see why that disqualifies other branches of the Emacs family tree from using the name that all of them inherit from the venerable TECO implementation. My point was that Emacsen have already been built in Common Lisp, but that they do not serve as substitutes for GNU Emacs--a point with which you appear to agree. Maybe we even agree on the reason why: because no Emacs implementation can substitute for GNU Emacs without supporting its ecosystem. The amount of work needed to do that would be enormous, whether the proposed substitute is written in Common Lisp or in something else.
- metroholografix 6y ago
  Sure, I just wanted to clarify and make it very clear that GNU Emacs in CL hasn't even been attempted since that was what the poster you originally replied to, equated "Emacs" with. As you said, the value lies primarily in the ecosystem. Common Lisp is by far the better language, but GNU Emacs is by far the most empowering/practical environment. I don't think enormous work would be needed, there are plenty of powerful shortcuts one could take (some ideas are in this thread) and Emacs Lisp can be made to run on top of Common Lisp but it's safe to say that for whatever reasons the will/intent is simply not there. Emacs Lisp is what we have to go on with and it's nice to see that it is not stagnating.

fiddlerwoaroof 6y ago

Robert Strandh is working on an Common Lisp emacs based on McClim but, McClim basically forces you to use linux.

fiddlerwoaroof 6y ago
There's also lem, which is more portable: https://github.com/cxxxr/lem https://github.com/cxxxr/lem