I want someone to add a Guile scheme interpreter to Zed and quietly turn it into an Emacs. I'd love to use Zed, but can't give up my Emacs keybindings and ability to describe-{mode,function,variable,etc}
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.
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
Probably nothing, but then this feature isn't aimed at people who have used emacs for years, and who like and effectively work with elisp.
I on the other hand, am very familiar with guile, I don't particularly care for elisp, and I would like to be able to customise my editor more comfortably. For me this is great.
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.
> 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.
> I would really like it if Magit was a standalone program
And what about Org, Org-Roam, Anki-editor, pdf-tools and org-noter, Eshell, gptel and chatgpt-shell, Transient, Vertico, Consult and Embark, Dired, Notmuch and mu4e, elfeed and elfeed-tube, consult-omni, gh-notify and code-review.el and many other nice things?
Sure, Emacs has many deficiencies - nothing is ever perfect. I too, would love to find something better, where those deficiencies are not. But tell me please, which alternative does allow you to do any of these things "reasonably" well?
Tell me, in which editor I can be taking my notes while also sending http requests, and queries to an sql database, while transforming the results in a higher-order language and then spitting out the data into a chart? Where I can also mark things in my notes for spaced repetition, without moving them anywhere, without converting anything. Where my notes can have LaTeX embedded formulas. Where I can type 'RFC 7230' in plain text and my editor would intelligently know what that is and allow me to browse the relevant document in-place. Where I can open any pdf and it would automatically locate my annotated notes. Where I can control the playback of any video - YouTube or whatnot, pausing it for note-taking, grabbing entire paragraphs of its transcript and putting them into my notes.
Tell me, which other editor has the notion of 'indirect buffers', where you can modify the same file working with it as if you're editing multiple files - where I can edit my code comments, treating them as if they are in markdown? Where you can freely edit your directory structure, using all editor features like multi-cursors and other things?
Tell me, which other editor allows me to search things in so many ways. Where else can I type a single query once and it sends out requests to Google, DuckDuckGo, Wikipedia, my browser history, GitHub, etc. and consolidates the results into a single buffer?
Bottom line: there just doesn't exist a reasonable option that is better than Emacs in the sense that it is free from its deficiencies and yet so versatile and powerful.
I agree with this. I've tried replacements. vscode(ium) was closest to giving me what I want, but in the end it really wasn't close. I always keep going back to Emacs, because I can do a lot of the little things that add up to a nice experience; and some of the not so little things. To me, Magit is a great example of what you can do with emacs. I love Helm and Deft too. But it's also those little things, some of which I've coded up for myself in a few lines of elisp.
BTW, those wanting an Emacs, but with Common Lisp rather than elisp can check out the lem-project on Github.
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.
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.
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.
When I hear concurrency, I just hear bugs and complexity. Imagine writing some code trying to adjust a package and dealing with concurrent logic. One of the thing that make emacs so easy to modify is the global state. With concurrency you will have to hide database-level code to deal with that, or replace it with a more complicated mechanism (actor models?).
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.
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
> 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.
I’m one of those “I use Emacs but only because of org-mode” people. I’m an associate professor, so I write a lot: research notes, lecture notes, course exercises, academic papers, task management, etc. Org lets me handle all that in an intuitive, plaintext-backed, keyboard-driven way. I haven’t been able to find something equivalent outside of Emacs, and believe me I’ve tried; the closest was Logseq but it doesn’t have the same editor functionality underneath, and orgmode.nvim + org-roam.nvim but there’s just too much missing still (for example, an equivalent to org-cdlatex-mode and a better table mode) and some features are blocked by issues in Vim and NeoVim themselves (e.g. the long-standing unresolved bug when combining “conceal” with soft-wrapped lines, which makes link hiding unusable). So I use Emacs, because this is a huge part of my workday and its best in Emacs.
But I’m really more a Vim guy. I’ve used it since the mid-2000s, still regularly use it, and all the keybindings and workflows just make sense to me. I even like vim9script as a language (I prefer it over Lua, but I do for sure like Elisp better). If it wasn’t for Org-mode I’d still be using Vim full-time.
> 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).
This describes virtually every editor on earth. In fact because macos leans so heavily on readline input, emacs comes with far more compatibility with native keybindings than VSCode does. IntelliJ is a downright horror show in this regard.
The runtime environment of emacs is definitely showing its age. Freezes and long pauses of non-interactivity are pretty common, although they do get fixed, new ones are regularly introduced. Separating the language fundamentals from the editor itself seems to show promise in opening up alternatives that allow competing with more modern editors on more even footing.
The ubiquity of readline is a bit of a myth. What happened was that Bash (thus Readline) and NeXT (thus MacOS) independently copied Emacs keybindings, where Emacs predates both. But the Mac GUI doesn’t use the Readline library, and differ in some points (e.g. M-f works in Readline but not MacOS). Moreover, it seems a lot of people think Readline is used everywhere in the CLI, but many popular interpreters use other libraries. For instance, Bash uses Readline but Zsh and Fish uses their own things. Python has used Readline up until now, but is moving away in 3.13. IPython switched from Readline to prompt_toolkit many years ago. Readline was also not the first shell to adopt Emacs keybindings, it was preceded by Ksh IIRC.
I have nothing against Readline, and I understand where you’re coming from since this is often repeated online for some reason. I just want to point out that it’s actually emacs keybindings and not readline keybindings that is the correct term here :)
I called them readline bindings because more people are familiar with readline than emacs. Furthermore macos certainly doesn't take enough of emacs outside of readline bindings to make me comfortable referring to them as emacs bindings.
I hadn't even noticed that zsh and fish used something other than readline. To me, they effectively are using readline as that's the name for the functionality that's fulfilled.
I don't really give a damn what they're called or why they exist, so I'll happily call them emacs bindings if that makes more sense to you.
> Furthermore macos certainly doesn't take enough of emacs outside of readline bindings to make me comfortable referring to them as emacs bindings.
That’s fair. But on the other hand they also don’t implement any of the Readline keybindings that are not in Emacs, like for example C-w and C-u to delete the last word and line, respectively.
> I hadn't even noticed that zsh and fish used something other than readline. To me, they effectively are using readline as that's the name for the functionality that's fulfilled.
IMO, that’s like calling Vim and Emacs for “TextEdit” because that’s what they do. I see the argument, but it is confusing.
Readline is one particular library, and it is relevant to many users like me whether it’s used or not. Many alternatives (as used by Fish and IPython for example) have better support for modern features like multi-line editing and syntax highlighting. Conversely, if MacOS actually used libreadline, I should have been able to enable Vi mode in .inputrc and get Vi keybindings in every MacOS text field, which I think many Mac users would want. But alas, MacOS ignores .inputrc, although there is a somewhat equivalent DefaultKeyBinding.dict. If you customize your .inputrc it also quickly becomes apparent that Fish and Zsh for example ignore your Readline settings.
> I just want to point out that it’s actually emacs keybindings and not readline keybindings that is the correct term here :)
Not least, because Readline also supports Vi keybindings (`set editing-mode vi` in `.inputrc`), it just defaults to Emacs keybindings (equivalent to `set editing-mode emacs`).
Sure but nobody's going to refer to the non-default bindings as "readline" bindings. Meanwhile cli prompts are where most users are exposed to emacs bindings.
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.
Yeah absolutely, but I'd argue only a tiny subset of that benefits from being integrated with an editor (mainly the parts I listed, jumping to changes and managing the staging area).
I think you can make the case that editor integration with Git is objectively better for the use cases I listed, but a lot of what Magit does is just alternative UI to what Git CLI provides, but I'd have a hard time making the case that either is better than the other, just different.
I always assume when people are asking for Magit in other editors, they just want the parts that are objectively better than Git CLI, but I'm not really sure which is why I asked the question.
If the only antiquated defaults are the ones you listed we're not in a bad shape at all...
Curious about light/dark mode, what does it do more than loading a theme? something like circadian.el? maybe it's because I hide menu-bar/tool-bar/scrollbars by default but `M-x load-theme modus-operandi` is all I need for whenever a room is too bright or a colleague complains about my dark theme.
always thought the problem was not multi-threading per se but the whole rendering code that's single threaded with tons of global state that's difficult to decouple without breaking the ecosystem
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.
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 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.
lazygit is a TUI app, IMHO that's a step back. I have many reflections on the widespread anachronism that is emulating a 60s piece of hardware - wanna make a blog post about it, but tl;dr imagine you're writing software for a GameBoy Color instead.
You can't even select multi-line text or use ctrl-c to copy text. It's not all that far from being limited to A/B/start/select/d-pad.
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.
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.
rms is a blocker of CL emacs, which I would like to see (and use). Relative to the guile, CL implementations are of great quality, rich set of libraries, ...
There would be no speed improvement, because the guile jit will not beat the existing native aot compilation via the libgccjit. It will be rather slower. But it will have proper concurrency support, and access to a wide area of guile libs. And a proper jit, which Stallman blocked for decades because of evil dll's.
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...
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.
"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.
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.
