emacs and guile (Re: ehelp woes, or why I hate a module that I love so much)

[Ken Raeburn <raeburn@raeburn.org>]

Juanma Barranquero <lektu@terra.es> writes:
> Ken Raeburn has a page on Guile-based Emacs (http://www.mit.edu/~raeburn/guilemacs/),
> but it was last updated on 1999-07-07. Ken is subscribed to this list,
> so I suppose he can comment on it.

Yeah, I was just looking today at how old that page is....

Yes, I've been working on it slowly and quietly, as my free time
allows.  I'm working on it because it interests me, I'd like more
opportunities to work with Scheme, I'd like to encourage others to
work with Scheme, I think it would get Guile more attention (including
its deficiencies in some areas, which hopefully would be readily
identified with a huge application like Emacs and addressed), and I
really want Simon to write those Gnus patches :-).  How threads at the
Scheme level might translate up to the UI, though, I have no idea.

The first batch of work I did, which resulted in the state described
on that web page, caused a fairly large and painful divergence, and
keeping up with new stuff being added to Emacs proved to be a big time
sink.  So I stopped that work, and started a different approach,
namely making some of the Lisp internals in the main FSF sources
easier to isolate and replace.  Hence the ENABLE_CHECKING,
HIDE_LISP_IMPLEMENTATION, and other changes to add all sorts of
compile-time and run-time checks, and the associated (functionally
invisible, I hope) transformations I've been applying to various
patterns throughout the sources to make more use of lisp.h macros.

(BTW, I've got a patch that adds configures option to turn on
ENABLE_CHECKING, or just the use of a union for Lisp_Object.  Should I
check it in?  I've noticed one or two people have been checking in
fixes for Lisp_Object/int mixups, for which I'm grateful, but I'd like
to encourage more of that checking as people write the code in the
first place.)

At this point, int, float and cons values, and to a lesser degree
strings, should be easy to rip out and reimplement.  Converting other
types to Guile's SCM type would be trickier because of a difference in
type handling.  Guile's C-level type extension system involves
allocating Scheme objects which have some application type information
and a pointer to the application data.  In the current Emacs system,
on the other hand, most of the type and pointer information is all in
the Lisp_Object value, and the "==" comparisons require that the
handle value be unique; you could call XSETBUFFER on a Lisp_String
pointer and it wouldn't complain.  So, should XSETBUFFER for Guile
create one of these Scheme objects, or should it use one allocated
earlier?

My approach last time around was to add a SCM field to most of the
"interesting" data types (symbol, misc, and vectorlike), fill it in
when the object was created, and make XSETFOO just copy the value out.
Rather crude, and wasteful of storage space, but it got the job done,
and it minimized the intrusion in random Emacs code and kept it
running with both object representations.

I want to try eliminating more of the XSETFOO calls outside of object
creation, in places where for example a simple assignment will do
instead.  But if I can't get most of them, I may have to use that same
approach again.

Since with the string macro stuff I've been changing in the last few
days, I've nearly reached the point I had in my old development tree
with regard to isolating those types I thought I could easily replace.
(I was starting to work on strings but hadn't finished them.  Vectors
would be easy except for the bits of code that group them with the
"vectorlike" types like buffers.)  So I'm thinking about starting a
branch soon and starting on some actual Guile code again.  Once the
branch is made, it should be much, much easier to get other people
involved.

Smooth interaction between the languages will need a lot more time,
but an Emacs that uses the Guile storage system and can communicate
with Scheme code, even if only by passing a few simple object types,
is certainly doable; I had a proof-of-concept implementation up and
limping long ago, but not remotely ready to be evaluated in terms of
memory use, performance, etc.

So, that's roughly what the current status is of my work....

Ken