This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

guile+emacs project, looking for developers


I've got CVS space at the FSF now, and automatically maintained
mailing lists with web-accessible archives at sourceware.cygnus.com.
See http://www.mit.edu/~raeburn/guilemacs/ for info.  Greg, I'll try
to get the update for the Guile Projects page sent off soon.

At this point, I'd like to ask for some help with this project.  If
anyone is interested in helping, please let me know.  RSI problems and
a new job have slowed down my work on it quite a bit, so the
description and status probably aren't too different from last time I
sent mail about it, but here they are:


This project that I have started is for converting GNU Emacs to use
Guile as its programming language.  Support for Emacs Lisp will
continue to exist, of course, but it'll be through translation; the
Lisp engine itself will no longer be the core of the program.
Eventually, the Emacs Lisp translator and some Emacs components *may*
become useable from other Guile programs.

The short status summary, for people not interested in investing some
real time helping with development, hacking on both Guile and Emacs:
Forget it, scram, this stuff doesn't work, and it's a long way from
working.  It could take years.


The longer version, for those who want to help:

Actually, a fair amount of stuff is working at the moment.  It crashes
sometimes, and there's no way I'd trust it with my email, but it pops
up windows, it reads files and colors them in font-lock mode, it
browses directories, it plays hanoi, it eats up virtual memory, lots
of basic Emacs stuff like that.

At the moment, I know of three specific problems: sometimes the window
height values come out wrong resulting in out-of-bounds array
references, causing it to crash; sometimes the logic for deciding
whether to put a menu bar on a frame gets the wrong answer (probably a
simple bug); and Emacs's input handling scheme can cause Lisp
evaluation to happen during garbage collection.  I haven't tried much
complex stuff that's likely to stress it.

But there's a lot of work remaining.  I've actually only done a small
part of it so far.

----------------

So far, I've replaced the basic object representation with that of
Guile, switched the allocator and garbage collector to be Guile's, and
I'm using Guile objects for numbers and cons cells.  All the objects
that aren't using Guile's basic types are using new "smob" types; the
vector and misc types are still subtyped as in normal Emacs.

I'm working on switching to Guile strings next, but since Guile
strings don't have multi-language support or text properties, that'll
take a little more work....  After strings come symbols; symbol
bindings are represented differently, so that may also take some
thought.

We also need to deal with, in no particular order:
 - input handling (do less stuff in signal handlers)
 - converting vector and "vectorlike" and "misc" types (in progress)
   - converting vectors is important
   - other types easy to convert, but not so important
   - any code operating on vectors and "vectorlike" must continue to
     work on both
 - switching to Guile evaluator
   - mdj's module syntax changes for translating emacs lisp source
   - jimb's nil/()/#f proposal for inter-language compatibility
   - writeup and discussion of the inter-language issues
   - elisp bytecode translation
 - writeup of changes visible from Lisp (e.g., changed obarray internals)
 - funcall stack
 - numeric support other than small integers
 - convert exception handling
 - testing & bugfixes
 - performance
 - multilingual support
   - for Guile proper (jimb may have someone working on it soon)
   - converting Emacs to use it
   - interim hacks probably layered on top of string support?  or
     jammed into basic Guile string support?
 - testing & bugfixes
 - performance
 - interactive debugging support (a la edebug)
 - threads
 - testing & bugfixes
 - performance

There are some parts of Emacs I'm not very familiar with, especially
the MULE support and display handling.  There's also a lot about Guile
and Scheme in general that I'm not all that familiar with.  If you
think I'm taking a poor approach technically to some part of this
project, or want to tackle some interesting aspect of the project that
you know a lot about, please let me know.  I could use the help.

Ken

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]