[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile-emacs for gsoc

From: Andy Wingo
Subject: Re: guile-emacs for gsoc
Date: Wed, 07 Apr 2010 22:58:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)


Briefly, as time grows short: I'm excited that you're interested in
hacking Guile into Emacs. I can offer some mentorship, though my
bandwidth is a bit strained at this point. I would prefer if someone
else stepped up to mentor, though I will do it if no one else can.

Also, the project is a bit nebulous at this point -- Ken has come at it
from the C-and-emacs side, and Daniel, Neil and I have come at it from
the Elisp-in-Guile side, and it's really unclear what's in the middle.
That's part of the hack, is finding that out.

The job seems to me more of painstakingly correct refactorings than of
strokes of creative brilliance. You do have to be a bit daring -- the
whole project is a little crazy -- but precise in the execution.

Still interested? I would be very happy to accept a proposal from you.
But please, do us all a favor, and really immerse yourself in the state
of things as they are now, as much as is possible tomorrow -- raeburn's
guilemacs tree and Guile's elisp implementation.

> One obvious project would be to finish up the Emacs Lisp
> implementation; I just started looking at it last night, so I don't
> know how complete it really is.

I don't really know that either. Daniel probably knows best; but I know
that there is some work to do on Guile's elisp still: the compiler needs
to take advantage of advances in Guile's compiler (prompts/aborts,
"native" fluid binding, optional/keyword args) -- unfortunately
documenting some of this is still next on my to-document list.
(literally next)

> Another might be to go ahead with replacing the Emacs Lisp evaluator
> even if Guile's Emacs Lisp implementation is not quite complete,
> enough to get it booting (and then improving the Emacs Lisp language
> implementation would have immediate benefits).

This would be good; but tough, as I mentioned.

> And then there are side
> projects like writing a bytecode interpreter.

I don't think we should be interpreting existing compiled elisp
bytecode. we should compile elisp source to guile's vm.

What do you think?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]