In support of guile-emacs

[Christopher Allan Webber]

There's been a lot of conversation on this list that's been discussing
whether or not the Guile port of emacs could be a good basis.  I've
advocated it in the past, and I'm advocating it further here.  I think
it's a solid direction, but what it really needs is *work* at this
point.  If you'd read the list lately though, you'd think the move was
on the order of getting a settlement on Mars.  But much of the work has
already been done.

guile-emacs (for lack of a better term at the moment) works, and it
works already.  Here's a screenshot I took 5 months ago:

  http://dustycloud.org/tmp/guile-emacs-20150513.png

And a less nice screenshot, but even back in February:

  http://dustycloud.org/tmp/guilemacs.png

I can run orgmode, I can hack lisp, I can play tetris!  Most of my
.emacs loads along with all the extensions implied.  Most of the things
I do day to day in emacs already work.  There is much work to be done,
and I'll come back to this, but I want to re-emphasize: guile-emacs is a
*real thing* you can try *today*.  In fact, if you have the Guix package
manager, you can try it right now, because I packaged it for Guix:

  guix package -i guile-emacs

Take a minute and think about it... that means that *a hell of a lot of
the things that already need to be done are already done*!

So guile-emacs runs, and unlike many other discussions that have been
discussed on list... is a real thing!  A thing you can use today!

But there is work to do.  The main thing that is needed is someone needs
to step up and *do this work*!

 - More work likely needs to be done on the strings side, but solutions
   have been discussed on list, and even in the case of transforming
   from bytevectors -> guile strings and back again, it's no big deal.
   I mean, there's work *to do*, but it isn't an impossibility.  We have
   the means of abstraction, and this can be achieved.
   Nonetheless, it seems like we're cycling nonstop on this issue,
   but it really just needs to be *worked on*.

 - It's slow.  But it's slow for mostly known reasons!  When I last
   talked to BT Templeton about this, they told me that they had a list
   of optimizations to do, especially around supporting dynamic scoping
   aspects.

 - There are bugs I ran into, but far fewer than expected.  More
   astounding is just how much works at this stage, IMO.

The "emacs rewrite" thread originally started out with "is C not a
maintainable language, and should it be rewritten in scheme?"  I
personally think emacs' C core is fine, but maybe over time things can
be refactored more into emacs lisp, or if guile-emacs were chosen,
scheme.  (I hear that Ludovic thinks libguile may replace much of it
anyway, but this is hardly my area.)  There's some other conversation on
the list that seemed to suggest something more hip to attract current
developers, but I think "The Emacs Problem" still applies: there's
nothing more flexible than s-expressions out there, and emacs maximizes
that:

  https://sites.google.com/site/steveyegge2/the-emacs-problem

I personally think Guile Emacs is an amazing project with a potentially
brilliant future ahead.  It is missing something though, and that's
regularly active hackers.  BT Templeton's work has broken a lot of
ground, though the project could use more active people.

The current guile-emacs FUD on list, I think it's pretty repetitive
and uninteresting.

But if you're really interested in a Glorious Emacs Future (TM),
guile-emacs might actually be that future you want!  You can try it
right now, it already runs!  (Just expect rough edges!)  And if you want
to make that future happen, it would be great to see you dig in.