"what are the differences between resurrected GuileEmacs that was also announced in EmacsConf2024 and Gypsum? At first glance seems like both projects have the same goal."
Response from @ramin_hal9001@fe.disroot.org
@ram535 thanks for asking! The goal for both projects are similar, but they are achieved in slightly different ways.
Gypsum is a clone written in Scheme, meaning it is software the behaves exactly like Emacs, but it is written from scratch in a new code base. In this case, it is also being written in a completely different programming language, Scheme instead of C. The larger goal is to have an Emacs that is backward compatible with GNU Emacs but is written in Scheme that runs on any R7RS standard compliant Scheme implementation. There is no C code in this project at all, it is purely Scheme. I would like to also target other compilers such as MIT Scheme, Gambit, Stklos, and possibly Chicken and Larceny as well, though this will be pretty difficult and rely on a lot of cond-expand code. The larger goal is to have an Emacs app platform that encourages the use of the Scheme language for creating applications and text editing work flows, regardless of the underlying compiler.
@lispwitch ‘s “GuileEmacs” is not a clone, but a fork of both GNU Emacs and GNU Guile, meaning it modifies the existing GNU Emacs code base and some of the Guile source base, replacing some of the C source code in GNU Emacs with other C source code from Guile. Then, the Emacs Lisp interpreter written in C is replaced with an Emacs Lisp interpreter written in Guile Scheme. This allows Emacs Lisp to be JIT compiled using Guile’s JIT compiler, and also make use of all of the Guile software ecosystem to extend Emacs. This is incredibly useful, because there is quite a lot of Guile software, including things like web servers and game engines, and soon it could all be available for use by Emacs programmers. It will probably also be production ready much sooner than my Gypsum project because it only needs to implement the core of Emacs Lisp to work. However, it relies on language features specific to Guile to achieve this, so it is not fully R7RS standards compliant, and will not work on other Scheme implementations.
Have you experimented with Edwin?
Edwin is a clone of GNU Emacs version 18 written in MIT Scheme.
https://www.gnu.org/software/mit-scheme/documentation/stable...
Can anyone tell me (a GNU Emacs user for 35+ years) something that I can't do in elisp but would be able to do if Guile was used instead?
One example that comes to mind is the delimited continuation primitive (what Guile calls a "prompt" [0]) that would allow for lightweight concurrency in elisp code, something that elisp is not good at today.
[0] https://www.gnu.org/software/guile/manual/html_node/Prompts....
there is a presentation on youtube (a new one)
https://www.youtube.com/watch?v=yjC162DnsKI&t=594s
for me the most interesting point, guile will allow emacs to be more lispy, replace c code with guile code and integrate with CLISP and CLISP libraries
For people who are more involved in this world than me: What're the chances of actually getting a supported full feature parity version of guile emacs? Like not anytime soon but, say, in the next 10 years.
It's my understanding it would be a significant speed improvement but the amount of work and the - ahem - stallman factor are big roadblocks.
What's your rush, sonny? You say 'not anytime soon' but then you say 'next 10 years'. In the world of GNU software, to say 'glacial pace' is basically asking 'what's your hurry?' Fine wine, fine wine... give it at least 30-40 years...
My recollection of past guile-emacs stuff is that rms is not a blocker here.
The biggest roadblocks are 1) lack of continued effort and 2) reticence on the Emacs side. I'd say 1) is the most important by far.
Although I think I understand Stallman and his role in Emacs pretty well, I cannot guess as to what "Stallman factor" refers to in this context.
I don't so it was a genuine question, checking if my understanding was correct. I guess it's more about the CL aspect.
From the article "Richard Stallman is not a fan of Common Lisp; rewriting Emacs using it is not likely to go far." My understanding is his preferences have a strong influence on emacs direction, which of course is well deserved, but he can be stubborn about things. I used "stallman factor" because it's not easy to sum up, as his strong opinions and influence on the project are both not bad things (even when I disagree with him I feel it's important to have someone like him) but they do prevent some avenues for improvement. Happy to be wrong about this.
I've been a "casual" Emacs user for 20ish years. I've never written a full-blown package, but went thru several cycles of init.el bankruptcy.
In my opinion and from my POV, Elisp is completely fine - no need to amend or replace it. The last thing I'd like is to mix yet another language into my config (already have to call out to shell and AppleScript).
Now I don't know how annoying Elisp is for package authors, or maybe there's a Guile/Scheme library somewhere out there that Emacs could desperately use.
The problems are IMHO elsewhere, and the main one is that Emacs feels antiquated next to literally any text editor conceived in the past 30+ years. The defaults are awful - most of my config is just fixing papercuts, like adding support for light/dark mode, finding a reasonable font and applying text size consistently, locating the correct LSP executable, or following platform conventions for copy/paste (all across Linux, OpenBSD, and macOS).
I would really like it if Magit was a standalone program, rather than an Emacs package, so that I could just switch to a more reasonable editor.
I don't think there is any plan to replace or even supplement ELisp with Guile Scheme. Guile is a language, but it is also a compiler and runtime. The later two have been intentionally designed such that different language front ends can be written to use them. The plan here is to use a new Elisp front end for the Guile compiler and runtime to replace Emacs' custom Elisp interpreter. Extensions and internal implementations will still be written in Elisp.
Wasn’t someone porting Emacs to run on Common Lisp? Or was just the C part of Emacs and building an eLisp on top of CL?
You might be thinking of https://lem-project.github.io/
> maybe there's a Guile/Scheme library somewhere out there that Emacs could desperately use.
It isn't the reason for Guile Emacs, but there is in fact a library Emacs could quite desperately use: fibers (<https://github.com/wingo/fibers>). The Emacs concurrency story is about as bad as you could expect from a 40+ year old application.
Oh, also, for new users who want to quickly smooth over a few papercuts, there's:
https://protesilaos.com/codelog/2024-11-28-basic-emacs-confi...
Also, a small point, you'll be thrilled to hear that an excellent "light/dark mode" is included in stock emacs since the modus-themes were beamed up into the mothership, which was several years ago at this stage.
>I would really like it if Magit was a standalone program, rather than an Emacs package, so that I could just switch to a more reasonable editor.
Magit (for me) has so much value _because_ it is part of Emacs , where I edit all my code.
> Magit (for me) has so much value _because_ it is part of Emacs , where I edit all my code.
Same. I'll never ever understand people saying "I use Emacs but only because of org-mode" or "I use Emacs but only because of Magit".
I use for Emacs for many things, hence org-mode and Magit have a lot of value to me. But they're not that amazing in themselves as to put up with Emacs only for one of these two.
Emacs is quite something: I don't think it's reasonable to use if only for either org-mode or Magit. You risk feeling bitter about it like GP.
don't tell this person: https://news.ycombinator.com/item?id=42421245
> I would really like it if Magit was a standalone program, rather than an Emacs package, so that I could just switch to a more reasonable editor.
Always curious with folks who request this whether they've tried `tig` (https://jonas.github.io/tig/)?
Not sure what part of Magit you're looking for, but the basic workflow of jumping to changes and interactive staging works just as well to me in `tig` (with Vim) as Magit.
Tig does about 10% of what Magit does, alas.
EDIT: It does the things it does well, but it's not even close.
You can always make magit behave as a standalone program if you wish. For example https://github.com/gizmomogwai/magit
I switched from vim to spacemacs back in 2017, (before recently switching to neovim). Emacs just seemed to have far superior packages compared to vim plugins (circa 2017), and with EViL mode honestly emacs just seemed like a better vim than vim for my use case. The performance though was never very good, but the feature set was amazing. I agree that Magit is hands down the best way to use git that's ever been created.
With my recent switch to neovim, I'd say that neovim is a lot better than emacs for me. I used kickstart.nvim as a launching point to base my config off of, and it's incredible! Neogit is a port of magit to neovim and while it's not quite as feature complete as magit, it's close enough when combined with DiffView.nvim and gitsigns.
Lua is a game changer versus vimscript and I'd say now that the gap in packages has been narrowed greatly and you can turn neovim into a pretty equivalently powerful dev environment to Emacs, while having vastly better performance.
You should try Doom emacs if you find spacemacs performances not good enough.
> The performance though was never very good,
to be honest mostly this is Spacemacs' fault. I left Spacemacs around the time you adopted it and I was shocked at how much more performant Emacs was without all the crap in Spacemacs' layers system
I haven't declared init.el bankruptcy since then, either.
> would really like it if Magit was a standalone program
check out lazygit
Agreed. Having gone through it several times myself, I don't even mind init.el bankruptcy once every 5-10 years. It's kind of rejuvinating to clean house and start anew. And these days the "starter kits" like Doom make it easy to setup sane defaults for 95% of what you want to do.
What really bothers me is the sluggish performance, especially when handling large numbers of buffers or even searching large files. Pretty sure fussing with Elisp is not going to fix that.
This is not about replacing Emacs Lisp with Guile. It is more about replacing the interpreter and the parts written in C with Guile. Emacs Lisp will still be the language for scripting and the code for the plugins shouldn't change much.
I understand native multithreading would be one of the key advantages of Guile Emacs.
I use lazygit as a ui. I like it. I think magit can do way more.
33 years here, and that's *exactly* where I am. Emacs... is fine. I mean, there are new features occasionally that are worth using. There are new paradigms it would be nice for it to support. But major architectural changes just seem silly. It's *done*. How many pieces of software ever get to say that? How many of those are entering their fifth decade of popular use?
Just leave elisp alone. I see nothing but grief and churn in this direction.
I feel like this as well sometimes. I have a pretty good setup there's been instances where things like activating the correct Python environment, have the LSP work properly or understand some arcane docs has been an issue. I don't see how Guile fixes any of this and it also suffers anemic docs imo.
Yeah defaults suck, but Starter kits have existed for a while: http://xahlee.info/emacs/misc/list_of_emacs_starter_kits.htm...
For me at least it took a few weeks initially to get a set up I liked but then have barely touched it in ~15 years. I suspect "better defaults" won't happen because it's not a continuing problem users have - like maybe you think about it when you're in the initial setup, but then it becomes less important to any developers.
It's an advanced tool, and typically advanced tools don't come out of the box ready to go.
> I suspect "better defaults" won't happen because it's not a continuing problem users have
As the plethora of startup kits and re-configurations show, it's also not something people can agree what the right thing (TM) is.
I would be in favour of the defaults being "prettified" or "modernised" a bit, but I don't agree that it's that big of an issue.
Actually, I'm not sure if there are any "major" issues... Development has been phenomenally good the last few years, the maintainers have been brilliant. There's a steady stream of contributors, new cool stuff (LSP support, native compilation, etc), improvements are happening regularly.
In summary, Emacs seems to be rock solid, and the quaint little splash screen when you run it for the first time does not seem close to keeping people away! Maybe we need to uglify it :)
But sure, yeah, prettier defaults, why not. I'm not convinced it'd suddenly get more people using Emacs, though, as Doom Emacs already exists, and that's very pretty and well-documented and modern-looking and so on.
Was it just me who read this as "User Guide for Emacs"
Given that Guile is unstable and full of rough edges on Unix and nearly unusable on Windows, I don't see that taking place any time soon. Even if they improve stability, the Emacs C VM (which is rock solid) is much more performant so they'd still need to climb that hill. And for what benefit? The ability to script Emacs in Javascript and Scheme? No thanks.
Advice to Robin: Find something else to spend your time on because this isn't going anywhere.
This is both rude and wrong. Congrats!