Re: Guile emacs thread (again)

[Eli Zaretskii]

> 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:
>   http://www.emacswiki.org/emacs/GuileEmacs
> 
> I remember reading Andy Wingo's email about this a few years ago,
> "guile and emacs and elisp, oh my!":
>   https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html
> 
> 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
support that.

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
and threads?

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?