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