I didn't know that there exists an Emacs clone written in Scheme. It is called "Edwin" and part of MIT/GNU Scheme.

> Edwin, the MIT/GNU Scheme text editor. Edwin is a clone of GNU Emacs version 18—you should refer to the GNU Emacs manual for information about Edwin’s commands and key bindings—except that Edwin’s extension language is MIT/GNU Scheme, while GNU Emacs extensions are written in Emacs Lisp. This manual does not discuss customization of Edwin.

is the scheme Guile?

There is an effort to port Emacs to Guile, with Guile providing an Emacs Lisp compatibility layer. That would have advantages in terms of performance and in terms of a more modern language. For example, Guile compiles to native code, and it also allows for better multi-threading support. Guile is also attractive because it is really made for extending C programs with Scheme, which is exactly the core architecture of Emacs. However, the Scheme **this** port mentioned above is using, is [MIT/GNU Scheme](https://en.wikipedia.org/wiki/MIT/GNU_Scheme), which is also a GNU project. It is an older implementation of Scheme, but among other things is has quite good debugging capabilities and cites itself "as being tailored to use in large and complex systems" .

Thanks. I look forward to the guile support. When I retire its guix and guile emacs for me!

There is [another clone too](https://www.emacswiki.org/emacs/GuileEmacs), written in Guile and was meant to replace Emacs core, but as the history has shown, that didn't happen.

Apparently there was an update this year on a couple of headers. But not much.

There's just too much mind share going to Emacs proper, I don't see the point. If someone wants a cool Emacs-like editor written in CL or Guile, they'll probably have to start from scratch.

Pretty much so, yes. A lot of specialized lisp primitives in Emacs, for text edition, window management etc, are written in C, and have to be re-written/implemented in the implementation language. [Lem is sort of a "spiritual clone"](https://github.com/lem-project/lem), not a 1:1 clone of Emacs, written in CL.

Thanks for the link, I don't see myself switching any time soon though =)

Not me either; I have invested too much time in Emacs to just switch; Emacs is my console, email reader, etc; and I am not so much for Electron apps either, but if you are interested in Emacs-like editors, it is a good application to look at. It has potential to one day replace GNU Emacs.

There were several clones most probably dead now. There is, of course, the original Emacs written in TECO and I remember using a version called “jove” Johnathan’s Own Version of Emacs

Multi-threading?

Don't be too exited. Emacs settled on optimizing emacs lisp via libgccjit instead of going down the guile-emacs route. This means that for Emacs Lisp fans, there is a fairly solid way forward in terms of arriving at better emacs lisp performance. And I personally don't think extending emacs with Guile Scheme would be something I like. In fact my first contact with lisps was Scheme and nowadays I will always pick preferentially a non-Scheme lisp (common lisp, emacs lisp) or Clojure before picking Scheme. It just feels anaemic in comparison.

Those who want to see Guile Emacs will have to contribute to making it a reality or it's never going to happen, because no one else is working on it at this point.

In case anyone wants to see it in action ca 1986, Hal Abelson demonstrates it in class somewhere in the first video [This should be the right link.](https://youtube.com/playlist?list=PLE18841CABEA24090)

That anemia is actually one of the reasons I'd like to see Emacs implemented in Scheme - mostly as a cure for the anemia. I love Scheme but way too much of the ecosystem is either missing, half-implemented, or under-documented. Consider how the elisp ecosystem has changed over the years - tons of general programming libraries and capabilities have been added, lots of libraries for handling specific file formats or interacting with specific APIs and services have been written, lots of documentation and articles and blog posts, etc. It's not because elisp is an especially great Lisp (I mean it's not bad, but I wouldn't write spacecraft control software in it), it's because Emacs guarantees it a userbase. I agree that it will probably never happen - the project was slow even back before the libgccjit efforts started. It's just a pity, that's all.

I would not call it dead. Developing Guile is a slow process, as it is infrastructure, and it is still worked on. Among other things, Guile has had significant performance improvements in the last years, and also progress in emulating in the way in which Emacs lisp handles strings.

> A lot of specialized lisp primitives in Emacs, for text edition, window management etc, are written in C, and have to be re-written/implemented in the implementation language. Well, Guile can call easily into C. I think the main difficulties of a port are: * different string handling in Scheme and Emacs Lisp * language differences, for example Emacs Lisp does not use lexical closures, which is antiquated by today's standards.

> Developing Guile is a slow process, as it is infrastructure, and it is still worked on. Of course; I meant Emacs on Guile. > also progress in emulating in the way in which Emacs lisp handles strings Ok. I am not overly interested in the project, so I don't monitor it frequently, I have looked at the repository and haven't seen any commits since 2015. But good if they still work on it. Observe, this wasn't a critique; I understand developing an Emacs clone is not an easy task, and Emacs development during last years seems to have ramped up too.

> Well, Guile can call easily into C. Sure; but not into Emacs C code. Nothing can "call easily" Emacs C code, since Emacs C code is not written to be "called into". No parts of Emacs original Lisp engine, or editor, or waht do you want to call it, are compiled as a shared, or even static library. Emacs is compiled into one, statically linked executable file, when it comes to Emacs own C code. You can't just include emacs C files into your application, or call into Emacs executable binary from your C code. It is not how it works. Emacs can (and does) load other shared libraries, but Emacs own C code is *not* a shared library that can be loaded and called by other applications. Edit: I don't understand why a downvote :-). It is not me critiquing or being unconstructive, it is just a fact about how Emacs is compiled, and how C language and compilers work :).

"Edwin" is not dead, it is used in MIT Scheme as development environment. There is also work to bring Emacs lisp to native-code compilation: https://old.reddit.com/r/emacs/comments/g9vdd0/bringing_gnu_emacs_to_native_code_at_the_european/

And Guile itself is also making progress, too: https://www.gnu.org/software/guile/news/gnu-guile-300-released.html

The thing is that such a port is not meant to give up in compatibility with elisp and all the elisp libraries which are around; it would just move the base implementation to scheme and provide an elisp interpreter on to of that - similarly as [Racket has moved its implementation to Chez scheme, while staying 100% compatible with existing Racket code](https://blog.racket-lang.org/2020/02/racket-on-chez-status.html). And after that, people can continue to configure and write Emacs in elisp, but they can also call into Scheme. Which would mean that many GNU projects share a common Scheme implementation and a library that is used in, say, Guix, can also be used in Emacs, and so on.

> The thing is that such a port is not meant to give up in compatibility with elisp and all the elisp libraries which are around; it would just move the base implementation to scheme and provide an elisp interpreter on to of that Yes. We all understand that.

Racket on Chez is not 100% compatible, though.

> is the scheme Guile? Guile is a Scheme implementation. Racket is another one, so is Chez, Chicken etc. Guile is meant to be embedded in other applications as a scripting language, similar to ECL in CL world, if you are familiar with that one.

How different is emacs lisp from scheme and sbcl ?

Especially now that Emacs Lisp has JIT.

n.b. This feature (native compilation) was released as part of Emacs 28.1, back in April of this year (just mentioning because, to me, your phrasing suggests it's still a development feature). It is opt-in though -- you need to enable it when building Emacs.

There is an [interesting talk by Tom Tromey](https://archive.fosdem.org/2020/schedule/event/emacsthoughts/) on this subject of implementing Emacs in other terms, you probably wish to take a look at it.

This comparison tells a few differences: https://stackoverflow.com/questions/8433474/what-are-the-major-differences-between-emacs-lisp-and-common-lisp See also these: * https://old.reddit.com/r/emacs/comments/4wxebi/is_there_any_difference_between_lisp_and_elisp/ * https://www.emacswiki.org/emacs/CommonLisp * https://www.emacswiki.org/emacs/EmacsLispLimitations Scheme is, like Common Lisp, a language standard, and is much more minimalist. Its implementations share the same language but differ in many other aspects. SBCL is a very popular and technically very solid implementation of Common Lisp. Common Lisp is often considered one of the most mature Lisps and has, in difference to Scheme implementations, managed to define a dominating standard. It implementations often do have very good runtime performance. But it is also relatively large.

Racket is kind of a fork off Scheme (also supporting most Scheme extension standards) and [Clojure also has quite some things in common with Scheme (link)](https://clojure.org/reference/lisps). For example, both are Lisp-1. And these two are the most successful recent new Lisp implementations. And Guile is the base of GNU Guix, which demonstrates well enough that one can build very large, stable systems with it.

> It's not because elisp is an especially great Lisp (I mean it's not bad, but I wouldn't write spacecraft control software in it), it's because Emacs guarantees it a userbase. And that is because Emacs emulates the Lisp platform as a general programming environment, like the Lisp machines (where even drivers were written in lisp and could be debugged during execution in the source editor).

> (I mean it's not bad, but I wouldn't write spacecraft control software in it) Actually, [NASA has written spacecraft control software in Lisp, debugging a race condition it over the air during a mission](https://thenewstack.io/nasa-programmer-remembers-debugging-lisp-in-deep-space/).

There is another potential advantage: There are a lot of Lisp programmers which know Common Lisp or Scheme, but not Emacs Lisp. Transitioning to a more standard language would increment the pool of developers which can contribute to Emacs.

[deleted]

SBCL is an implementation of Common Lisp. Another one is for example CCL or CLISP etc. It is like GCC and Clang, albeit with more annoying differences :). Emacs Lisp and CL share some common grounds, and Emacs is relatively close to Common Lisp in some basic parts, but there are lots of things missing, notably namespaces and reader macros, and weaker condition system. It is definitely closer to CL than to Scheme.

Quite of those links you are posting are outdated and inaccurate in context of modern Emacs developmnet. Those links should be updated. Speed issues are largely overcome with more primitives implemented in C, some reworked and of course with native compilation being introduced. Emacs has also got lexical scoping, albeit in somewhat limited form. Seems you seem to be reading a lot of links and googling info, I suggest you to [read a paper on Emacs Lisp evolution](https://dl.acm.org/doi/abs/10.1145/3386324) by S. Monnier & Co, and I suggest watching that video by Tom Tromey I posted to you earlier. By the way; I didn't want to be a party pooper earlier, but dude, most of us are aware of Edwin, MIT Scheme, Guile and all that you are just discovering. It has been there for years. Watch the talk if you didn't already, and you will probably understand the direction of Emacs current development and why the Guile Emacs has stalled. Edwin and MIT Scheme seems to have stalled a long time ago, probably because GNU Emacs has developed so much faster and simply offers a better alternative to an old Emacs implementation.

> But it is also relatively large. [Common Lisp the Language, 2nd Edition](https://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html), which describes the de facto standard, is over a thousand pages. CL is basically the kitchen sink Lisp.

>I don't understand why a downvote a) vote fuzzing. You may not have been downvoted at all. b) don't whine. No one likes a whiner.

Yes, but not elisp.

I suspect elisp is the most well-known lisp at this point.

But that includes a large standard library.

That's the thing about Lisp, the line between language and library is considerably fuzzier than most languages. And for a large standard library, it's missing some pretty notable stuff, like, oh, networking.