4 ms·

Is there still any work being done on Guile Emacs? As I recall it basically worked a few years ago, but it doesn't seem to be maintained. I'm curious if these 3

by hencq 7y ago

Is there still any work being done on Guile Emacs? As I recall it basically worked a few years ago, but it doesn't seem to be maintained. I'm curious if these 3.0 speedups would translate there too.

bjoli 7y ago
Guile runs elisp just fine, although there are quite some low hanging optimization fruit to be picked. From the Emacs side I strongly doubt it will happen. The discussions that have been going on for faaaar less intrusive changes is staggering. Reading the discussions about the portable dumper (new in the upcoming emacs 27, proposed in 2014) is a nice 4 hours. That was in just about every measurable way a step forward for Emacs, yet it took almost 4 years for it to be mainlined,despite glibc more or less deprecating the old unexec from under emacs' feet. I might be misrepresenting just about everything here, but one thing I am pretty certain of: guile Emacs will never happen, despite the promises of running elisp on guile.
- pzone 7y ago
  > Guile runs elisp just fine While this may be the case, my understanding was that once the codebases were combined and guile-emacs builds were brought online, they encountered a severe performance drop from vanilla Emacs due to back-and-forth string conversion between Guile's Unicode strings and the Emacs internal enhanced string type. I thought that the project was abandoned after finding no obvious resolution to the problem short of a complete rewrite of all Emacs string handling.
  - bjoli 7y ago
    That was only a problem for scheme interop, since guile's elisp uses emacs extended UTF8 strings.
- yepguy 7y ago
  I think it could potentially happen by way of a fork, similar to the history of GCC and EGCS, but it would take a dedicated group of hackers to make it happen. Not one guy doing all the work and a bunch of Guile fans on the sidelines cheering for him.
  - bjoli 7y ago
    I agree! I am not that guy though, since I know enough C to understand I could never contribute anything useful to emacs :D
- outworlder 7y ago
  I thought people at my workplace loved to schedule meetings and talk endlessly about things that could have been easily implemented in less time than the meetings took. Then I remember emacs-devel... and it's infuriating. There's bikeshedding, and then there's how to paint the bikeshed, discussions about bikeshed compliance, if bikeshed should be called GNU/Bikeshed, if the bikeshed even supports non open-source bikes and how to make the bikeshed not compatible with them, and that's before the feature itself is even discussed. Even if it is already implemented and there's an actual patch. > guile Emacs will never happen Universe heat death is still far away, there's always hope.
  - davexunit 7y ago
    changing anything in GNU (with a few exceptions) is like pulling teeth. it is endlessly frustrating. every proposed change, no matter how small, will be met with essay length responses from the old guard about why it shouldn't be changed. just one example of many: gnu.org is still managed via a cvs repo because rms doesn't like git and it doesn't matter to him that newcomers find it to be a roadblock. it's amazing that anyone has the patience to swim against that current and improve things.
deng 7y ago
No, I don't think anyone's working on this. It is also very unclear if it is really worth the effort (for a good overview see https://lwn.net/Articles/615235/ https://lwn.net/Articles/615235/ from Stefan Monnier, Emacs' ex-maintainer). For speeding up Emacs Lisp, I think the current work done by Andrea Corallo using libgccjit is more promising. Another big boost would probably be to replace the current regex engine with something better.
- agumonkey 7y ago
  thanks for the news, and yeah considering the amount of time emacs extension spend re-searching faster regexes would probably translate to big speed increases
- khc 7y ago
  The objection seems to be that guile supports more than just elisp. Surely if emacs switch to guile it can disable other languages?

by hencq 7y ago

Is there still any work being done on Guile Emacs? As I recall it basically worked a few years ago, but it doesn't seem to be maintained. I'm curious if these 3.0 speedups would translate there too.

bjoli 7y ago

Guile runs elisp just fine, although there are quite some low hanging optimization fruit to be picked. From the Emacs side I strongly doubt it will happen. The discussions that have been going on for faaaar less intrusive changes is staggering. Reading the discussions about the portable dumper (new in the upcoming emacs 27, proposed in 2014) is a nice 4 hours. That was in just about every measurable way a step forward for Emacs, yet it took almost 4 years for it to be mainlined,despite glibc more or less deprecating the old unexec from under emacs' feet. I might be misrepresenting just about everything here, but one thing I am pretty certain of: guile Emacs will never happen, despite the promises of running elisp on guile.

pzone 7y ago
> Guile runs elisp just fine While this may be the case, my understanding was that once the codebases were combined and guile-emacs builds were brought online, they encountered a severe performance drop from vanilla Emacs due to back-and-forth string conversion between Guile's Unicode strings and the Emacs internal enhanced string type. I thought that the project was abandoned after finding no obvious resolution to the problem short of a complete rewrite of all Emacs string handling.
- bjoli 7y ago
  That was only a problem for scheme interop, since guile's elisp uses emacs extended UTF8 strings.
yepguy 7y ago
I think it could potentially happen by way of a fork, similar to the history of GCC and EGCS, but it would take a dedicated group of hackers to make it happen. Not one guy doing all the work and a bunch of Guile fans on the sidelines cheering for him.
- bjoli 7y ago
  I agree! I am not that guy though, since I know enough C to understand I could never contribute anything useful to emacs :D
outworlder 7y ago
I thought people at my workplace loved to schedule meetings and talk endlessly about things that could have been easily implemented in less time than the meetings took. Then I remember emacs-devel... and it's infuriating. There's bikeshedding, and then there's how to paint the bikeshed, discussions about bikeshed compliance, if bikeshed should be called GNU/Bikeshed, if the bikeshed even supports non open-source bikes and how to make the bikeshed not compatible with them, and that's before the feature itself is even discussed. Even if it is already implemented and there's an actual patch. > guile Emacs will never happen Universe heat death is still far away, there's always hope.
- davexunit 7y ago
  changing anything in GNU (with a few exceptions) is like pulling teeth. it is endlessly frustrating. every proposed change, no matter how small, will be met with essay length responses from the old guard about why it shouldn't be changed. just one example of many: gnu.org is still managed via a cvs repo because rms doesn't like git and it doesn't matter to him that newcomers find it to be a roadblock. it's amazing that anyone has the patience to swim against that current and improve things.

deng 7y ago

No, I don't think anyone's working on this. It is also very unclear if it is really worth the effort (for a good overview see https://lwn.net/Articles/615235/ https://lwn.net/Articles/615235/ from Stefan Monnier, Emacs' ex-maintainer). For speeding up Emacs Lisp, I think the current work done by Andrea Corallo using libgccjit is more promising. Another big boost would probably be to replace the current regex engine with something better.

agumonkey 7y ago
thanks for the news, and yeah considering the amount of time emacs extension spend re-searching faster regexes would probably translate to big speed increases
khc 7y ago
The objection seems to be that guile supports more than just elisp. Surely if emacs switch to guile it can disable other languages?