public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
* Emacs Scheme interface
@ 2000-03-27 22:51 Keisuke Nishida
  2000-03-28  4:01 ` Kalle Olavi Niemitalo
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Keisuke Nishida @ 2000-03-27 22:51 UTC (permalink / raw)
  To: guile-emacs

Hello,

Since we have now got the ability to access Lisp functions from
Scheme programs, it may be about the time to think about a better
Emacs Scheme interface.

The current implementation of importing Lisp functions is not
quite convenient.  We have to write ((point)) instead of (point)
to get the point as a number.  It is easy to define point so that
(point) returns a number, but mixing both normal imported functions
and other special versions such as the (point) mentioned above may
be very confusing.  We should think about a whole new set of Emacs
Scheme procedures.

Some functions can be easily imported by always converting return
values to Scheme objects.  Some may be difficult because modifying
the Lisp value is essential (e.g., keymaps).  Some requires defining
new Scheme object in onder to get proper processing (e.g., buffers).

Since we have to think about all Lisp primitives, this will take a
long time.  But we have to do that step by step.  This work will be
useful in the future because we can reorganize Emacs primitives/
procedures/macros in terms of Scheme.  The new API will not be changed.

As soon as the next version of Guile Emacs is released, this project
can be started.  People may define a new module (emacs api) (or whatever)
and put new definitions in it.  The new API should be documented so
that people do not confuse.

Unfortunately, I don't have enough time to work on this for a while.
But let's start discussing.

-- Kei

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-27 22:51 Emacs Scheme interface Keisuke Nishida
@ 2000-03-28  4:01 ` Kalle Olavi Niemitalo
  2000-03-28 10:27   ` Keisuke Nishida
  2000-03-28 11:43 ` Kalle Olavi Niemitalo
  2000-03-31 17:48 ` Keisuke Nishida
  2 siblings, 1 reply; 14+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-28  4:01 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> It is easy to define point so that (point) returns a number,

And I think it should be defined that way.

> but mixing both normal imported functions and other special
> versions such as the (point) mentioned above may be very
> confusing.

If a Lisp reference is needed, one can call
(lisp-eval '(current-global-map)).

> Some functions can be easily imported by always converting return
> values to Scheme objects.  Some may be difficult because modifying
> the Lisp value is essential (e.g., keymaps).

If Emacs Scheme treated keymaps as opaque objects like XEmacs
does, that would be easier to solve.  But I suppose RMS wouldn't
approve that.

> Some requires defining new Scheme object in onder to get proper
> processing (e.g., buffers).

That's right.  They should probably also be associated with GOOPS
classes.

> People may define a new module (emacs api) (or whatever)
> and put new definitions in it.

IIRC, SCWM keeps its modules under (app scwm ...).  Perhaps Emacs
modules should be (app emacs ...).

> Unfortunately, I don't have enough time to work on this for a while.
> But let's start discussing.

I would really like thread support in Emacs Scheme.  Multiple
threads should be able to process different buffers at the same
time.  Perhaps the "current buffer" should be thread-local.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-28  4:01 ` Kalle Olavi Niemitalo
@ 2000-03-28 10:27   ` Keisuke Nishida
  2000-03-28 11:37     ` Ken Raeburn
  2000-03-28 23:06     ` Kalle Olavi Niemitalo
  0 siblings, 2 replies; 14+ messages in thread
From: Keisuke Nishida @ 2000-03-28 10:27 UTC (permalink / raw)
  To: Kalle Olavi Niemitalo; +Cc: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> If a Lisp reference is needed, one can call
> (lisp-eval '(current-global-map)).

I don't think it is a good interface.  It is harder to understand and
may not work in the future.

I think a better way to get around this is to define a GOOPS class
for keymaps and define suitable procedures which call Lisp functions
appropriately as you may think in your mind.  If (current-global-map)
always returns a list, we can't do that.

> IIRC, SCWM keeps its modules under (app scwm ...).  Perhaps Emacs
> modules should be (app emacs ...).

Is that a convention among Guile applications?  If there is no such
convention yet, we should talk to the Guile team.  In my opinion,
such a declaration like (use-modules (app emacs majormode scheme))
is a little bit long...  An Guile application often adds its own
primitives (e.g., lisp-eval) and the scheme programs does not work
with other applications, which means the scheme programs should be
installed separately from Guile's shared directory, so omitting
`app' will not hurt anyone.

> I would really like thread support in Emacs Scheme.  Multiple
> threads should be able to process different buffers at the same
> time.  Perhaps the "current buffer" should be thread-local.

Me too, but as long as we use the current Lisp functions, it may be
hard to work around...  Have you tried Guile's multithread supoprt
with Guile Emacs?  Does it work well?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-28 10:27   ` Keisuke Nishida
@ 2000-03-28 11:37     ` Ken Raeburn
  2000-03-28 23:06     ` Kalle Olavi Niemitalo
  1 sibling, 0 replies; 14+ messages in thread
From: Ken Raeburn @ 2000-03-28 11:37 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: Kalle Olavi Niemitalo, guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:
> > I would really like thread support in Emacs Scheme.  Multiple
> > threads should be able to process different buffers at the same
> > time.  Perhaps the "current buffer" should be thread-local.
> Me too, but as long as we use the current Lisp functions, it may be
> hard to work around...  Have you tried Guile's multithread supoprt
> with Guile Emacs?  Does it work well?

It won't if you try using Lisp in more than one thread -- dynamic
variable bindings (function arguments, "let") are implemented in a way
that is thread-unfriendly.  That's one of the reasons I decided to
start by converting the lower-level code to use Guile -- to get clean,
working threads.

If you only use Scheme in the extra threads, it might be okay, but
there are places where Emacs can invoke Lisp code from signal
handlers.  (Sad but true.)  I've no idea what impact that would have.

Emacs 21, it appears, will have conservative GC that scans the stack.
So switching stacks out from under it would be really unfriendly.

Once we get to the point of being able to provide multiple threads in
Lisp, we still have to figure out what the UI effects should be...

Ken

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-27 22:51 Emacs Scheme interface Keisuke Nishida
  2000-03-28  4:01 ` Kalle Olavi Niemitalo
@ 2000-03-28 11:43 ` Kalle Olavi Niemitalo
  2000-03-28 12:23   ` Keisuke Nishida
  2000-03-31 17:48 ` Keisuke Nishida
  2 siblings, 1 reply; 14+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-28 11:43 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs

Many Emacs Lisp special forms like `save-excursion' take a list
of expressions to evaluate.  In Scheme, it seems more common to
instead take a thunk to call: `dynamic-wind' and
`with-input-from-file' work this way.

Should the Scheme versions of `save-excursion' and others be
changed to take a thunk parameter?  (Then they wouldn't even have
to be macros.)

The macros are more convenient, though.  Perhaps we should
provide both a procedure `call-saving-excursion' and a macro
`save-excursion'.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-28 11:43 ` Kalle Olavi Niemitalo
@ 2000-03-28 12:23   ` Keisuke Nishida
  2000-03-29  2:33     ` Kalle Olavi Niemitalo
  0 siblings, 1 reply; 14+ messages in thread
From: Keisuke Nishida @ 2000-03-28 12:23 UTC (permalink / raw)
  To: Kalle Olavi Niemitalo; +Cc: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> Many Emacs Lisp special forms like `save-excursion' take a list
> of expressions to evaluate.  In Scheme, it seems more common to
> instead take a thunk to call: `dynamic-wind' and
> `with-input-from-file' work this way.
> 
> Should the Scheme versions of `save-excursion' and others be
> changed to take a thunk parameter?  (Then they wouldn't even have
> to be macros.)

I think everything in Scheme should be organized in the way of Scheme,
including the naming style.  In that sense, the new save-excursion
should take a thunk parameter.

> The macros are more convenient, though.  Perhaps we should
> provide both a procedure `call-saving-excursion' and a macro
> `save-excursion'.

Maybe... but having two different expressions may be confusing.
Does Guile have any macro like `save-excursion'?  If so, providing
it as a macro would be OK.  If not, only call-saving-excursion might
be enough.  I prefer consistency to convenience.  One may define
one's own convenient syntax in Scheme.  (Good defaults are important,
though...)

Maybe the new (emacs macro) should provide those convenient macros?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-28 10:27   ` Keisuke Nishida
  2000-03-28 11:37     ` Ken Raeburn
@ 2000-03-28 23:06     ` Kalle Olavi Niemitalo
  2000-03-29 16:57       ` Keisuke Nishida
  1 sibling, 1 reply; 14+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-28 23:06 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> > (lisp-eval '(current-global-map)).
> 
> I don't think it is a good interface.  It is harder to understand and
> may not work in the future.

But at least it is easy to grep for "lisp-eval" when there is a
better interface.  It is more difficult to convert from the
current ((point)) syntax.

> I think a better way to get around this is to define a GOOPS class
> for keymaps and define suitable procedures which call Lisp functions
> appropriately as you may think in your mind.

I wasn't actually thinking of GOOPS, just some unspecified
structure (a bare #<lisp-reference> could do) and procedures to
access it.

I don't have anything against GOOPS though :-)

> If (current-global-map) always returns a list, we can't do that.

Right, it should return some object through which the real keymap
can be modified.  This object can be a Lisp reference like now or
something specific to keymaps.

When importing a procedure, we should think of the value it
returns.  Numbers and strings should be copied.  Lists perhaps
too, if they are short and don't have to be modified in place.
Keymaps and strange objects like buffers can be Lisp references
for now; new Scheme types should be defined later.

I suppose things would be easier with Ken Raeburn's patches.  :-)

> Is that a convention among Guile applications?

Module naming has been discussed on the Guile list (I have
archives beginning from Feb 1999), but I don't think there was a
conclusion.

> omitting `app' will not hurt anyone.

True, nobody else is going to have a top-level `emacs' package.

> Have you tried Guile's multithread supoprt with Guile Emacs?

I haven't.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-28 12:23   ` Keisuke Nishida
@ 2000-03-29  2:33     ` Kalle Olavi Niemitalo
  2000-03-29 17:09       ` Keisuke Nishida
  0 siblings, 1 reply; 14+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-29  2:33 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> I think everything in Scheme should be organized in the way of Scheme,
> including the naming style.

Naming style -- do you mean the question marks, or something else?

> Does Guile have any macro like `save-excursion'?

Actually, Guile has `save-module-excursion' which takes a thunk
parameter.  So I suppose `save-excursion' should take a thunk,
and the convenient macro (if we provide one) should be called
something else like `begin-save-excursion'.

> Maybe the new (emacs macro) should provide those convenient macros?

That would be convenient.  :-)

Here is a mostly tested implementation.  I did not commit this to
CVS because I suppose this shouldn't be in 0.3 yet.

;;; (emacs emacs)

(define (lisp-macro->procedure lisp-macro)
  "Return a procedure which calls LISP-MACRO.
The returned procedure accepts one argument, THUNK.  It calls
LISP-MACRO with one argument: a form which comes back to Scheme and
calls THUNK."
  (lambda (thunk)
    "Call some Lisp macro, passing it a form which calls THUNK."
    (lisp-eval `(,lisp-macro (scheme-eval '(',thunk))))))

(define (lisp-macro-1->procedure lisp-macro)
  "Return a procedure which calls LISP-MACRO.
The returned procedure accepts two arguments, PARAM and THUNK.  It
calls LISP-MACRO with two arguments: the quoted PARAM, and a form
which comes back to Scheme and calls THUNK."
  (lambda (param thunk)
    "Call some Lisp macro, passing it PARAM and a form which calls THUNK."
    (lisp-eval `(,lisp-macro ',param (scheme-eval '(',thunk))))))

;;; (emacs import)

(define-public save-excursion
  (lisp-macro->procedure 'save-excursion))

(define-public with-current-buffer
  (lisp-macro-1->procedure 'with-current-buffer))

;;; (emacs macro)

(define-macro (define-begin-macro macro-name procedure)
  "Define a macro MACRO-NAME which calls PROCEDURE with a thunk.
The thunk evaluates the macro arguments when called.
MACRO-NAME is an unevaluated symbol.  PROCEDURE is any expression
evaluating to a procedure, such as a variable.  It is evaluated
where `define-begin-macro' is called."
  `(define-macro ,macro-name
     (let ((procedure-val ,procedure))
       (lambda body
	 "Call some procedure with a thunk which evaluates BODY."
	 `(',procedure-val (lambda () ,@body))))))

(define-macro (define-begin-macro-1 macro-name procedure)
  "Define a macro MACRO-NAME which calls PROCEDURE with a parameter and a thunk.
The thunk evaluates the other arguments when called.
MACRO-NAME is an unevaluated symbol.  PROCEDURE is any expression
evaluating to a procedure, such as a variable.  It is evaluated
where `define-begin-macro-1' is called."
  `(define-macro ,macro-name
     (let ((procedure-val ,procedure))
       (lambda (param . body)
	 "Call some procedure with PARAM and a thunk which evaluates BODY."
	 `(',procedure-val ,param (lambda () ,@body))))))

(define-macro (define-public-begin-macro macro-name procedure)
  "Like `define-begin-macro', but also export MACRO-NAME."
  `(begin
     (define-begin-macro ,macro-name ,procedure)
     (export ,macro-name)))

(define-macro (define-public-begin-macro-1 macro-name procedure)
  "Like `define-begin-macro-1', but also export MACRO-NAME."
  `(begin
     (define-begin-macro-1 ,macro-name ,procedure)
     (export ,macro-name)))

(define-public-begin-macro begin-save-excursion save-excursion)

(define-public-begin-macro-1 begin-with-current-buffer with-current-buffer)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-28 23:06     ` Kalle Olavi Niemitalo
@ 2000-03-29 16:57       ` Keisuke Nishida
  0 siblings, 0 replies; 14+ messages in thread
From: Keisuke Nishida @ 2000-03-29 16:57 UTC (permalink / raw)
  To: Kalle Olavi Niemitalo; +Cc: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> > > (lisp-eval '(current-global-map)).
> > 
> > I don't think it is a good interface.  It is harder to understand and
> > may not work in the future.
> 
> But at least it is easy to grep for "lisp-eval" when there is a
> better interface.  It is more difficult to convert from the
> current ((point)) syntax.

Either is not good.  That's why I think we should think of a better
interface soon.

> When importing a procedure, we should think of the value it
> returns.  Numbers and strings should be copied.  Lists perhaps
> too, if they are short and don't have to be modified in place.
> Keymaps and strange objects like buffers can be Lisp references
> for now; new Scheme types should be defined later.
> 
> I suppose things would be easier with Ken Raeburn's patches.  :-)

We can use GOOPS without changing the current C level interface,
as I wrote in another email; however, if we want to create GOOPS
objects automatically according to the type of return values from
Lisp functions, adding class information to Lisp references may be
convenient:

  (define (lispref->object lispref)
    (let ((obj (make (lispref-class lispref))))
      (set! (lispref obj) lispref)
      obj))

  (lispref->object (lisp-eval '(current-buffer))) => #<<buffer> ...>

Note that we cannot always rely on the value of lispref-class
since Emacs uses integers as the representation of characters.
We want to distinguish integers and characters in Emacs Scheme.
(Is there any way to do that correctly?)

(I guess we'd better always create Scheme integers instead of
references to Lisp integers for performance reasons.  This breaks
consistency, but that would be okay since programmers is discouraged
from using lisp-eval directly.  Maybe we should rename it %lisp-eval
or something.)

-- Kei

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-29  2:33     ` Kalle Olavi Niemitalo
@ 2000-03-29 17:09       ` Keisuke Nishida
  2000-04-30 12:08         ` Kalle Olavi Niemitalo
  0 siblings, 1 reply; 14+ messages in thread
From: Keisuke Nishida @ 2000-03-29 17:09 UTC (permalink / raw)
  To: Kalle Olavi Niemitalo; +Cc: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> > I think everything in Scheme should be organized in the way of Scheme,
> > including the naming style.
> 
> Naming style -- do you mean the question marks, or something else?

Something like that (? for predicate, ! for side effect, etc).
What could I way?  Naming scheme?

> > Does Guile have any macro like `save-excursion'?
> 
> Actually, Guile has `save-module-excursion' which takes a thunk
> parameter.  So I suppose `save-excursion' should take a thunk,
> and the convenient macro (if we provide one) should be called
> something else like `begin-save-excursion'.

I agree with this.  And your implementation looks good.  Thanks!

-- Kei

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-27 22:51 Emacs Scheme interface Keisuke Nishida
  2000-03-28  4:01 ` Kalle Olavi Niemitalo
  2000-03-28 11:43 ` Kalle Olavi Niemitalo
@ 2000-03-31 17:48 ` Keisuke Nishida
  2000-03-31 22:42   ` Klaus Schilling
  2 siblings, 1 reply; 14+ messages in thread
From: Keisuke Nishida @ 2000-03-31 17:48 UTC (permalink / raw)
  To: guile-emacs; +Cc: guile

Hello,

This is an idea of the new low level interface between Lisp and Scheme
that uses GOOPS for Guile Emacs.

Construction Process
--------------------

1. When one calls lisp-eval in Scheme, that calls Feval (the Emacs's
   eval function) internally.

2. Feval returns a Lisp object.  We have to create a corresponding
   Scheme object.  If the object is directly convertible to a Scheme
   object, we will do so.  However, since we want to share storage
   between Lisp and Scheme, we are going to create a kind of reference
   to the Lisp object.  We call it an instance of Emacs Object that is
   a GOOPS class.

  - Class: <emacs-object>

    An abstract class to hold Lisp objects.  Subclasses of this
    class are actually used.

  - Class: <emacs-pair>
  - Class: <emacs-string>
  - Class: <emacs-vector>
  - Class: <emacs-buffer>
  ...

3. We want to return the same Emacs object for the same Lisp object.
   We need a table to manage this relationship.  Let's think of it
   as a pair of vectors:

     Lisp object vector:  [obj0][obj1][obj2][obj3][...]
   Scheme object vector:  [obj0][obj1][obj2][obj3][...]

   The elements of the Lisp vector are Lisp objects.  The elements of
   the Scheme vector are corresponding Emacs objects mentioned above.
   We can traverse the Lisp vector to find the index of a Lisp object
   and thus the corresponding Emacs object.  An Emacs object should
   have a slot that keeps the index so that we can efficiently find
   the corresponding Lisp object.  (Or it could have a slot to hold
   a Lisp object directly, but we need the index slot anyway as
   described below.)

   This vector implementation is not very efficient, but I'm going to
   write this as the initial implementation because of its easiness.
   The Lisp vector is also used to protect those Lisp objects from GC.

4. We have to create a new Emacs object if it has not been done.  We
   put a Lisp object in the vector, get the index, and make a Emacs
   object with the index like this (but in the C level):

     (make <emacs-object> #:index index)

   The class is practically determined by the type of the Lisp object.
   We put this object in the Scheme vector for later reference.

5. The Emacs object found/created is returned as the value of lisp-eval.

Modification Process
--------------------

Since Emacs uses the same object type for several different concepts
(e.g., integers for characters, lists for sparse keymaps), we want to
distinguish them.  This could be done like this:

  (define-class <emacs-keymap> (<emacs-object>) ...)

  (define (current-local-map)
    (make <emacs-keymap> #:value (lisp-eval '(current-local-map))))

This is not sufficient since it does not always return the same value.
We need to change the class some way like this:

  (define (current-local-map)
    (let ((keymap (lisp-eval '(current-local-map))))
      (%change-emacs-object-class! keymap <emacs-keymap>)
      keymap))

This may be a little bit tricky, so I am not sure if we should do this.

Application Process
-------------------

Once lisp-eval returns a GOOPS object, we can import a Lisp function
and use it like this:

  (define (buffer-string)
    (lisp-eval '(buffer-string)))

  (define-method string-ref ((string <emacs-string>) (n <integer>))
    (lisp-eval (list 'aref string n)))

  (string-ref (buffer-string) 0)  --> 123

If a Emacs object is used as an argument of a Lisp function, it is
automatically converted to the corresponding Lisp object due to the
table defined above, so we don't need to care about that.  We can use
both <string> and <emacs-string> as an argument of the function insert:

  (define insert (string)
    (lisp-eval (list 'insert string)))

  (insert "hello")              ;; OK
  (insert (buffer-string))      ;; OK

If we need to operate an Emacs object by using Scheme procedures,
an explicit conversion is necessary.  It can be done like this:

  (define-method eval-string ((string <emacs-string>))
    (eval-string (%emacs-object->scheme string)))

  (eval-string (buffer-string))

At this level, most operations of lisp variables/functions except
dynamic references can be done transparently, and the code can be
used with the Guile-based Emacs in the future.  (See below for how
to handle dynamic bindings in Scheme.)

Destruction Process
-------------------

When an Emacs object is garbage-collected, we also have to remove
the corresponding Lisp object from the table.  We can use the index
slot of the Emacs object to find the location.

In the vector implementation, we can replace the Lisp object by nil.
That field can be used later.  If there are too many nil fields, we
should squeeze the elements.

Dynamic Bidings
---------------

Dynamic bidings, including references to buffer/frame-local variables,
are done this way:

  (define (lisp-variable-ref var)
    (lisp-eval var))

  (define (lisp-variable-set! var val)
    (lisp-eval `(setq ,var ',val)))

  (define buffer-file-name
    (make-procedure-with-setter
     (lambda () (lisp-variable-ref 'buffer-file-name))
     (lambda (value) (lisp-variable-set! 'buffer-file-name value))))

  (set! (buffer-file-name) "hello")
  (insert (buffer-file-name))

Note that we can't write without parentheses like (insert buffer-file-name),
which we can do with the current implementation.  We should explicitly
indicate what we are doing by using parentheses (and it's less tricky).

I think these interfaces can be used in the future and make it easier
to switch to Guile-based Emacs whenever it is appropriate.

-- Kei

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-31 17:48 ` Keisuke Nishida
@ 2000-03-31 22:42   ` Klaus Schilling
  2000-04-01  9:02     ` Keisuke Nishida
  0 siblings, 1 reply; 14+ messages in thread
From: Klaus Schilling @ 2000-03-31 22:42 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs, guile

Keisuke Nishida writes:
 > Hello,
 > 
 > This is an idea of the new low level interface between Lisp and Scheme
 > that uses GOOPS for Guile Emacs.

How will goops interact with eieio ?

Klaus Schilling

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-31 22:42   ` Klaus Schilling
@ 2000-04-01  9:02     ` Keisuke Nishida
  0 siblings, 0 replies; 14+ messages in thread
From: Keisuke Nishida @ 2000-04-01  9:02 UTC (permalink / raw)
  To: Klaus.Schilling; +Cc: guile-emacs, guile

Klaus Schilling <Klaus.Schilling@munich.netsurf.de> writes:

>  > > How will goops interact with eieio ?
>  > 
>  > What is eieio?
>  > 
> A partial CLOS-Implementation for Emacs Lisp.
> ftp://ftp.ultranet.com/pub/zappo

This is interesting, but do we need to do anything special with it?
If one wants to convert it into a GOOPS object, I think one can do
that during the modification process that I call.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Emacs Scheme interface
  2000-03-29 17:09       ` Keisuke Nishida
@ 2000-04-30 12:08         ` Kalle Olavi Niemitalo
  0 siblings, 0 replies; 14+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-04-30 12:08 UTC (permalink / raw)
  To: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> I agree with this.  And your implementation looks good.  Thanks!

I have now committed the `begin-save-excursion' changes.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2000-04-30 12:08 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-27 22:51 Emacs Scheme interface Keisuke Nishida
2000-03-28  4:01 ` Kalle Olavi Niemitalo
2000-03-28 10:27   ` Keisuke Nishida
2000-03-28 11:37     ` Ken Raeburn
2000-03-28 23:06     ` Kalle Olavi Niemitalo
2000-03-29 16:57       ` Keisuke Nishida
2000-03-28 11:43 ` Kalle Olavi Niemitalo
2000-03-28 12:23   ` Keisuke Nishida
2000-03-29  2:33     ` Kalle Olavi Niemitalo
2000-03-29 17:09       ` Keisuke Nishida
2000-04-30 12:08         ` Kalle Olavi Niemitalo
2000-03-31 17:48 ` Keisuke Nishida
2000-03-31 22:42   ` Klaus Schilling
2000-04-01  9:02     ` Keisuke Nishida

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).