[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile emacs thread (again)
Re: Guile emacs thread (again)
Sun, 14 Sep 2014 19:20:22 +0300
> From: Christopher Allan Webber <address@hidden>
> Date: Thu, 11 Sep 2014 11:29:09 -0500
> Anyway, it seems that BT Templeton's emacs on guile project this summer
> has gone fairly well, and it looks like almost everything runs. See:
> I remember reading Andy Wingo's email about this a few years ago,
> "guile and emacs and elisp, oh my!":
> I found it very inspiring. It seems those things are fairly close.
> So this email is partly a:
> - What now? What's the chance of work towards guilemacs moving over to
> an official emacs git branch, and that port happening, anytime soon?
Well, the "User-visible issues" there sound pretty scary to me.
Evidently, even building it, and even on GNU/Linux, is not without
problems ("it compiles and starts up if you struggle a little").
Please also note the "best just test on GNU/Linux for now" comment,
and a similar TODO item "find beta testers for non-GNU platforms".
This matches my experience with Guile -- it needs some serious work to
be reasonably portable to platforms other than GNU. Right now, too
many important features will be simply disabled if the configure
script finds they are not provided by the standard libraries. Emacs
is eons ahead of that.
And it doesn't help that one needs a hacked version of Guile for this
(i.e. have 2 different Guile versions installed on the same machine).
So IMO, Someone® should invest a non-trivial amount of work to at
least resolve the main issues mentioned on the TODO page. Otherwise,
I doubt that someone will consider using such an Emacs for serious
work, and without that it will never get past the alpha-testing stage,
whether it is an official branch of the Emacs repo or not.
Also, I think there are some design issues that need to be discussed,
rather than decided by a single individual, because the considerations
for how to unify Guile with Emacs, i.e. which Emacs objects and
methods should be based on Guile, are entirely non-trivial. One
example is non-ASCII text and string representation -- AFAICS
GuileEmacs wants to convert them back and forth from/to Scheme
strings, but the internal representation of text in Emacs is not 100%
UTF-8, it has a couple of extensions, and it's not clear how best to
Another potential issue is (or could be) the use of mmap for buffer
memory -- I guess the current build simply sidesteps that because mmap
isn't used on GNU/Linux, but otherwise how would this play with libgc
I'm sure these 2 are just the tip of an iceberg.
> (I'm mid-compile of the guile wip branch right now...!)
Did you succeed?
- Guile emacs thread (again), Christopher Allan Webber, 2014/09/13
- Re: Guile emacs thread (again),
Eli Zaretskii <=
- Re: Guile emacs thread (again), Grim Schjetne, 2014/09/16
- Emacs Lisp's future (was: Guile emacs thread (again)), Stefan Monnier, 2014/09/16
- Re: Emacs Lisp's future (was: Guile emacs thread (again)), Lennart Borgman, 2014/09/16
- Re: Emacs Lisp's future (was: Guile emacs thread (again)), Jorgen Schaefer, 2014/09/17
- Re: Emacs Lisp's future, Lars Brinkhoff, 2014/09/17
- Re: Emacs Lisp's future (was: Guile emacs thread (again)), Lally Singh, 2014/09/17
- Re: Emacs Lisp's future (was: Guile emacs thread (again)), Alexis, 2014/09/17
- Re: Emacs Lisp's future, Daniel Colascione, 2014/09/18
- Regular expression creation [was: Re: Emacs Lisp's future], Alexis, 2014/09/18
- Re: Regular expression creation [was: Re: Emacs Lisp's future], Aurélien Aptel, 2014/09/18