Using Guile for Emacs

https://lwn.net/SubscriberLink/1001645/b1e4453a8c6c16d7/

by todsacerdoti • 2 years ago

183 71 2 years ago

klik993• 2 years ago

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.

hollerith• 2 years ago

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.

klik993• 2 years ago

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.

Iwan-Zotow3• 2 years ago

RMS refuses and blocks efforts to move to CL Emacs.

That would be a revolutionary development, not that Guile garbage

davexunit3• 2 years ago

My recollection of past guile-emacs stuff is that rms is not a blocker here.

Iwan-Zotow3• 2 years ago

rms is not a blocker here

huh?!?

he was and is actually supporter of guile-emacs

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, ...

lloda• 2 years ago

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.

llm_trw2• 2 years ago

3) what's the point?

It's not like the pool of guile developers is much larger than the pool of elisp developers.

And guile has gotten worse for users in the 3.x series compared to the 2.x series.

This is coming from someone whose used it since 1.6 and gave up around 3.0.4 moving to racket.

blihp• 2 years ago

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...

rurban3• 2 years ago

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.

rurban3• 2 years ago

Ah, typo. A proper ffi of course

rollcat2• 2 years ago

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.

vfclists• 2 years ago

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.

pavon• 2 years ago

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.

rbanffy• 2 years ago

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?

klik993• 2 years ago

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.

ska• 2 years ago

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.

skydhash2• 2 years ago

Emacs, VIM, and a few others let you adjust them until you find a sastifying workflow. Other will have you bend backwards to modify the “defaults”.

Almost everything can be converted to a text workflow and emacs has a lot of features for text based interfaces.

Kototama• 2 years ago

You can always make magit behave as a standalone program if you wish. For example https://github.com/gizmomogwai/magit

ajross• 2 years ago

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.

skydhash2• 2 years ago

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?).

pton_xd• 2 years ago

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.

tcoff91• 2 years ago

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.

dingnuts• 2 years ago

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

forty• 2 years ago

You should try Doom emacs if you find spacemacs performances not good enough.

reddit_clone• 2 years ago

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.

TacticalCoder• 2 years ago

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.

robenkleene2• 2 years ago

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.

Quekid5• 2 years ago

Tig does about 10% of what Magit does, alas.

EDIT: It does the things it does well, but it's not even close.

tmtvl2• 2 years ago

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.

NeutralForest• 2 years ago

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.

sourcepluck2• 2 years ago

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.

sourcepluck2• 2 years ago

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.

hatmatrix• 2 years ago

I understand native multithreading would be one of the key advantages of Guile Emacs.

aulin2• 2 years ago

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

hibbelig• 2 years ago

I use lazygit as a ui. I like it. I think magit can do way more.

rollcat2• 2 years ago

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.

kagevf• 2 years ago

adding support for light/dark mode

It's there.

  M-x invert-face

Then, type "default"

Also, checkout M-x customize-themes for some other decent built-in themes.

aulin2• 2 years ago

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.

iLemming• 2 years ago

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.

drweevil• 2 years ago

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.

PittleyDunkin3• 2 years ago

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.

setopt4• 2 years ago

macos leans so heavily on readline input

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 :)

n_sd• 2 years ago

Was it just me who read this as "User Guide for Emacs"

armitron• 2 years ago

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.

davexunit3• 2 years ago

This is both rude and wrong. Congrats!

PaulDavisThe1st• 2 years ago

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?

systems• 2 years ago

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

davexunit3• 2 years ago

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....

bjoli• 2 years ago

Have a runtime separate from emacs where you could use things like "liborgmode" comes to mind.

steeleduncan• 2 years ago

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.

f1shy• 2 years ago

Multitasking

myaccountonhn• 2 years ago

Maybe tighter integration with guix? So that you can control your entire os (you’re using exwm right) just using one language

ram535• 2 years ago

"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.

soegaard• 2 years ago

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...

zellyn2• 2 years ago

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}

teddyh• 2 years ago

You could try Zile: <https://www.gnu.org/software/zile/>

zellyn2• 2 years ago

Well, it's Zed specifically that I want to be able to use, just with at least Emacs keybindings, and at most a skunkworks Emacs.

Using Guile for Emacs

Related Stories