public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: Keisuke Nishida <kxn30@po.cwru.edu>
Cc: rms@gnu.org
Subject: Re: guile-emacs-0.1 released
Date: Wed, 15 Mar 2000 21:07:00 -0000	[thread overview]
Message-ID: <tx1bt4fwliy.fsf@raeburn.org> (raw)
In-Reply-To: <m31z5e4ga4.fsf@kei.cwru.edu>

Keisuke Nishida <kxn30@po.cwru.edu> 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

  parent reply	other threads:[~2000-03-15 21:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-13 15:11 Keisuke Nishida
2000-03-14 12:46 ` guileapi.x problems [patch] Kalle Olavi Niemitalo
2000-03-14 13:20   ` Keisuke Nishida
2000-03-15 21:11   ` Ken Raeburn
2000-03-16  4:29     ` Kalle Olavi Niemitalo
2000-03-16  8:55       ` Keisuke Nishida
2000-03-16 16:57         ` Kalle Olavi Niemitalo
2000-03-17  9:55           ` Keisuke Nishida
2000-03-15 21:07 ` Ken Raeburn [this message]
2000-03-16 12:29   ` guile-emacs-0.1 released Keisuke Nishida
2000-03-16 18:50   ` Richard Stallman
2000-03-17  2:10     ` Ken Raeburn
2001-01-07  9:13       ` Richard Stallman
2001-01-07 13:28         ` Ken Raeburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tx1bt4fwliy.fsf@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=kxn30@po.cwru.edu \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).