From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ken Raeburn To: Keisuke Nishida Cc: rms@gnu.org Subject: Re: guile-emacs-0.1 released Date: Wed, 15 Mar 2000 21:07:00 -0000 Message-id: References: X-SW-Source: 2000-q1/msg00024.html Keisuke Nishida writes: > May I use the guile-emacs mailing list for discussions of this patch? > If anyone could help me, please let me know. (And could anyone correct > my English? please...) I've got no problem with this, if your intent is to move towards guile-based emacs, which is what I set the list up for. I'll try to catch up on the rest of this email very soon.... Speaking of which, I should probably report on my current status, as poor as it is... (not significantly changed from what I've reported before, but Keisuke and possibly others haven't heard): Unfortunately, I haven't done much on my guile-emacs project directly. I have done some work on the official Emacs repository, mostly working towards elimination of knowledge of the internal representation of Lisp_Object being used elsewhere. Most recently, I'm working on the "INTERVAL" type -- the "parent" field is overloaded, holding either a Lisp_Object or a pointer to another INTERVAL (or, in a few cases, a null pointer), and much code simply figures it out by examination, which won't work with another Scheme back end without hard-coding knowledge of the Scheme implementation. (I think it might be doable with Guile, but really, I don't think it's the right approach. I'm working on adding a flag to the interval structure to indicate whether it's the top of the interval tree, which indicates which element of the union of Lisp_Object and INTERVAL* to use. But there's some really tedious debugging to do, it keeps crashing.) Once I get the interval stuff done, I'd like to try merging into my guile-emacs repository again, and get back to work on that part of the project. I can't make Emacs use Guile strings until the interval code works with Guile objects. Symbols might be converted without waiting for strings to be done, but the interaction of Lisp dynamic bindings and buffer- and frame-local bindings and Scheme lexical bindings needs to be worked out. (IMHO, Scheme code should see Scheme behavior unless it requests access to the current Lisp environment. Which means dynamic bindings go someplace other than the Scheme value binding, and I have to pay more attention to the interaction of dynamic and buffer-local bindings, which I noticed RMS was working on recently. And then there's variables restricted to specific types, and with side-effects in the C code. How do we do this all in a generic way, not designed around Guile specifically?) Vectors need to be converted, and will probably be easy, but first the "vectorlike" types in Emacs need to be separated from "real" vectors because the vectorlike types will be new Emacs-application data types. None of this should depend on the work on strings and symbols. Etc.... But I do have a guile-emacs mostly working with Guile representations for numeric types and cons cells, and "smob" types for everything else. Separately from things at the C layer, which is where I feel most comfortable, there's the Lisp->Scheme translation. I've been experimenting with some of mdj's elisp branch in the Guile tree, trying to get rid of dependencies on new functions added to the C code (sorry, Mikael, @bind is just ugly to me) and set up a "Lisp environment" object that can be passed around, and manipulated separately in each thread, but I keep bumping into subtle things where my understanding of Scheme workings isn't solid enough. And, since I'm working with unreleased Emacs source code, I'm not at liberty to release copies of what I'm working on for people to work with (especially since the current Emacs maintainer, Gerd Moellmann, has requested that I not do so). My current guile-emacs repository is in the same state -- I've imported some of the emacs-21 work. Okay, so switching to the unreleased code was probably a mistake.... But, if people have FSF accounts and want to work on this, I'd love to have some help. Like I said, I'll get caught up on this email soon... Ken