Follow

It seems there's a lot of interest in continuing work on Guile Emacs, since it keeps coming up on Reddit and Hacker News and everyone is lamenting the fact that there are too few Scheme hackers and they don't seem to be interested in the project. (Someone even offered to fund it.)

Right now I'm seriously considering starting a revival project. Is anyone here interested in such a venture?


@guile @emacs @scheme

@erkin emacs that uses guile not elisp?

I'd use it for sure

@emsenn To recap: Guile Emacs was a project to replace Emacs's crufty old C-based Elisp interpreter with one written in Guile. This would, in addition to the significant performance benefits, allow one to use Guile as the extension language of Emacs.
Emacs was forked into Guile Emacs by Robin Templeton and developed alone between 2014-2015 before being abandoned. With the sole developer gone, it's been dead for a few years by now.

emacswiki.org/emacs/GuileEmacs

@erkin @emsenn I would absolutely love to see this revived. 😊 I've never really worked in Scheme before, but I would definitely learn it for the sake of performance improvements and more versatility in Emacs 😊

@erkin @emsenn It's not that hard to make a good Emacs-like editor, built entirely in any modern Lisp.

The problem with Emacs is that it's written in C, with Elisp as a scripting language. The C leaks everywhere.

The main value in Gnu Emacs is all the existing modes. They're tied to both Elisp, and the outdated architecture of Emacs. The big challenge in any Emacs replacement is get a competitive set of modes.

@tfb @erkin @emsenn

see Hemlock, (Second) Climacs and Lem for three emacslike editors already written in Common Lisp

@phoe @erkin @emsenn I should look at Lem, I've never done.

Hemlock is a great example of how Emacs could look (it's CL but it would look almost the same in Scheme). What's the matter with Hemlock? Nothing, it's used by both LispWorks and Closure CL for their editors. And the CMUCL version is fine.

But it's missing all the modes. And porting them would be just rewriting them, because they're tied to so much C code.

@tfb @emsenn
Guile Emacs doesn't seek to replace Elisp with Guile. The goal is to replace the C core of Elisp that is opaque and inaccessible from above with Guile, which would give us natively-compiled multithreaded Elisp with a high-performance garbage collector and full tail-call optimisation. (The lack of the latter is the reason low-level Elisp code uses dirty hacks to avoid hitting the stack depth limit when recursing over beefy procedures.)
So, ideally, it would be a drop-in replacement.

@erkin @emsenn
A drop-in replacement is crap.

Put another way: I could build you a nice Emacs in SCM. I've done it in the past with CLISP. But you can't load your modes into it because Gnu Emacs is badly factored by today's standards.

"Eight Megs And Constantly Swapping" was a real criticism. You couldn't run the damn thing on a PC until the 1990's, and even then it was maybe not a good idea.

Today we can afford good architecture in our editors.

@tfb @erkin @emsenn I remember being dismayed when I learned that Guilemacs was intended to be bug-for-bug compatible with Emacs's byzantine API. Here was a chance to *fix* things!

@tfb @erkin @emsenn Thus ad-hocness doth make cowards of us all
And thus the native hew of innovation
Is sicklied o're by the maintenance of cruft

@erkin I suspect the overlap between knowing Guile, knowing Emacs Lisp and knowing C is close to non-existent. I for example do not know Guile and don't plan to. How about you?

@wasamasa Yeah, finding enough people well-versed in all three is probably the biggest block in the road, especially considering how convoluted the C code in Emacs is. I know Guile and Elisp but my C knowledge is shaky at best. I'm just trying to see if it's feasible to gather people who can successfully collaborate on something like this.

@erkin @emacs if I don't end up being too busy this semester I might be able to dedicate a couple of hours to hacking on it

@erkin this is sadly one of those things everyone wants but no-one bothers because there already is a solution that's working alright, namely, Emacs itself.

I have mixed feelings wrt Guile Emacs. I fear the new languages that become available might take away from the unified experience Emacs has to offer (learn some Elisp and edit any config or package). OTOH, relying on a better lang VM would both allow for incorporating many improvements and relieve maintainers from a major burden.

@erkin @guile @emacs @scheme Yes, I would like to see that happen, at least see some movement. I have resurrected the guile-emacs package in GNU Guix a year or two ago and I think @cwebber packaged it initially.
I fear however that the biggest hurdle may not a technical one, but getting the mindset of Emacs hackers.

@erkin I would find that very interesting, guile based emacs makes so much sense to me from a technical point of view.

What I don't understand, probably by lack of reading background info, why this effort is not a part of the core roadmap. That is, why was/is there apparently no sufficient developer interest since the first effort.

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!