No new commits yet, just a talk about a future relaunch. Only strings performance is missing.<p>Gypsum <a href="https://emacsconf.org/2024/talks/gypsum/" rel="nofollow">https://emacsconf.org/2024/talks/gypsum/</a> started from guile-emacs afresh, but is way behind.
And with Andrea's elispjit the guile port is probably not needed at all.
Between this and things like Guix and Hoot, sometimes I feel like I could find incredible peace and happiness if I just sold all my possessions and moved into the Guile monestary, so to speak.
I wish Robin luck in relaunching the guile-emacs project! I hope that this talk will help the Emacs community understand the potential and be more open to the prospect this time around.
One of those "Never Ever" projects. The idea appeals to me, but most of the emacs user community seems uninterested so I don't think it will ever succeed. Nonetheless, Godspeed.
> <i>integrates Emacs and Guile by providing a new Elisp implementation based on Guile's Lisp-oriented compiler tower and runtime environment</i><p>I am hoping Guile the language (scheme) also will be supported alongside elisp.
Do we even want guile-emacs nowadays?<p>With native compilation i'd rather keep a sub-optimal but fast lisp (emacs lisp) than get a slow but (allegedly) better lisp (guile).
i have one question, for me emacs have only 1 major flaw (or you can call it drawback) , its slow, some extensions are very very slow , magit for me is the prime example , json-navigator is another<p>will this make emacs fast , i understand guile is a nicer language than elisp, but if its not significantly faster, this i think will go nowhere<p>(the second but minor flaw, it need better graphics, nicer ways to represent directory trees or git branches, other than ascii, but if emacs becomes fast, i can live with that)