* special forms (save-excursion) @ 2000-03-14 12:46 Kalle Olavi Niemitalo 2000-03-14 13:32 ` Keisuke Nishida 2000-03-14 14:11 ` Keisuke Nishida 0 siblings, 2 replies; 15+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-14 12:46 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs How are you going to handle special forms in guile-emacs? They can't be wrapped as easily as normal functions. Will their C source be rewritten for Guile? Below is a macro implementation of save-excursion. I have tested it with: (define (test) (save-excursion (goto-char (point-min)) (insert "hah"))) I also tried moving the mark-active-var binding to a separate let between define-syntax and syntax-rules, but that didn't work out. ================================================================= (use-syntax (ice-9 syncase)) (use-modules (emacs emacs) (emacs import)) (define set-marker (emacs-import-function 'set-marker)) (define make-marker (emacs-import-function 'make-marker)) (define mark-marker (emacs-import-function 'mark-marker)) (define-syntax save-excursion (syntax-rules () ((save-excursion body ...) (let ((mark-active-var (global-variable 'mark-active)) (outer-buffer *unspecified*) (outer-point (make-marker)) (outer-mark (make-marker)) (outer-mark-active *unspecified*) (inner-buffer #f) ; used as a first-time flag (inner-point (make-marker)) (inner-mark (make-marker)) (inner-mark-active *unspecified*)) (dynamic-wind (lambda () ;; save outer state (set! outer-buffer (current-buffer)) (set-marker outer-point (point)) (set-marker outer-mark (mark-marker)) (set! outer-mark-active (global-ref mark-active-var)) ;; restore inner state, if any (cond (inner-buffer (set-buffer inner-buffer) (goto-char inner-point) (set-marker (mark-marker) inner-mark) (global-set! mark-active-var inner-mark-active)))) (lambda () body ...) (lambda () ;; save inner state (set! inner-buffer (current-buffer)) (set-marker inner-point (point)) (set-marker inner-mark (mark-marker)) (set! inner-mark-active (global-ref mark-active-var)) ;; restore outer state (set-buffer outer-buffer) (goto-char outer-point) (set-marker (mark-marker) outer-mark) (global-set! mark-active-var outer-mark-active))))))) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-14 12:46 special forms (save-excursion) Kalle Olavi Niemitalo @ 2000-03-14 13:32 ` Keisuke Nishida 2000-03-14 14:11 ` Keisuke Nishida 1 sibling, 0 replies; 15+ messages in thread From: Keisuke Nishida @ 2000-03-14 13:32 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > How are you going to handle special forms in guile-emacs? > They can't be wrapped as easily as normal functions. > Will their C source be rewritten for Guile? That is a hard task. Probably the best way is to write equivalent macros in Scheme, as you did. For the moment, one easy way to do this kind of tasks is to use the emacs-eval procedure: (emacs-eval '(save-excursion (goto-char (point-min)) (insert "hah"))) Actually this might be better for efficiency, though not a good approach. I don't have a good idea about this yet. I'll try to think later. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-14 12:46 special forms (save-excursion) Kalle Olavi Niemitalo 2000-03-14 13:32 ` Keisuke Nishida @ 2000-03-14 14:11 ` Keisuke Nishida 2000-03-14 14:17 ` Keisuke Nishida 2000-03-15 0:34 ` Kalle Olavi Niemitalo 1 sibling, 2 replies; 15+ messages in thread From: Keisuke Nishida @ 2000-03-14 14:11 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > How are you going to handle special forms in guile-emacs? > They can't be wrapped as easily as normal functions. > Will their C source be rewritten for Guile? I think we shouldn't modify the C source until the time do so. The first priority is to provide a framework to write and evaluate Emacs Scheme files successfully, in my opinion. So, even it may be tedious and inefficient, I think we have to rewrite all macros in Scheme... If you could contribute some macros, I'd very appreciate it and include it in the distribution. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-14 14:11 ` Keisuke Nishida @ 2000-03-14 14:17 ` Keisuke Nishida 2000-03-15 0:34 ` Kalle Olavi Niemitalo 1 sibling, 0 replies; 15+ messages in thread From: Keisuke Nishida @ 2000-03-14 14:17 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > How are you going to handle special forms in guile-emacs? > They can't be wrapped as easily as normal functions. > Will their C source be rewritten for Guile? Oops, I misunderstood. I'm not going to write those macros in C for Guile, because it will be more hard and less portable. Let's do the easier one, and rewrite it when it becomes necessary. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-14 14:11 ` Keisuke Nishida 2000-03-14 14:17 ` Keisuke Nishida @ 2000-03-15 0:34 ` Kalle Olavi Niemitalo 2000-03-15 3:32 ` Keisuke Nishida 1 sibling, 1 reply; 15+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-15 0:34 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs [I'm on this list now] Keisuke Nishida <kxn30@po.cwru.edu> writes: > If you could contribute some macros, I'd very appreciate it and > include it in the distribution. Perhaps I can. But I tend to get bored with things so don't take this as a promise. Should the macros be in module (emacs import), if they correspond to Emacs features? If it were possible to pass Scheme procedure objects to Emacs Lisp and call them from there, save-excursion could use the existing primitive: (define-syntax save-excursion (syntax-rules () ((save-excursion body ...) (emacs-eval `(save-excursion (,(lambda () body ...))))))) This would convert the body forms to a Scheme thunk and then evaluate an Emacs form which calls that thunk within save-excursion. LAMBDA captures the current bindings so lexical scoping would be preserved. Here's another version which uses guile-eval instead of directly calling the procedure from Emacs. But it too needs the new type. (define-syntax save-excursion (syntax-rules () ((save-excursion body ...) (emacs-eval `(save-excursion (guile-eval '(',(lambda () body ...)))))))) You wrote you'd rename emacs-eval and emacs-apply. What are the new names? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-15 0:34 ` Kalle Olavi Niemitalo @ 2000-03-15 3:32 ` Keisuke Nishida 2000-03-15 5:11 ` Kalle Olavi Niemitalo 0 siblings, 1 reply; 15+ messages in thread From: Keisuke Nishida @ 2000-03-15 3:32 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > Should the macros be in module (emacs import), if they correspond to > Emacs features? A new module (emacs macro) might be better. > If it were possible to pass Scheme procedure objects to Emacs Lisp and > call them from there, save-excursion could use the existing primitive: > > (define-syntax save-excursion > (syntax-rules () > ((save-excursion body ...) > (emacs-eval `(save-excursion > (,(lambda () > body ...))))))) Well, in this way, you can't write this: (let ((start (point))) (save-excursion (goto-char start))) > Here's another version which uses guile-eval instead of directly > calling the procedure from Emacs. But it too needs the new type. > > (define-syntax save-excursion > (syntax-rules () > ((save-excursion body ...) > (emacs-eval `(save-excursion > (guile-eval '(',(lambda () > body ...)))))))) This looks better in this case. Probably many of Lisp macros can be implemented this way, except some others such as `unwind-protect' (but we already have `dynamic-wind'). I guess I should add the new Lisp type, but... a problem can be we have to convert Scheme's #t and #f into the special type instead of t and nil. But this may not be a problem since we can return a symbol t or nil to Lisp anyway. (And it can be done automatically in some way.) OK, I'll try to add the type soon. I guess you can define a new macro `import-lisp-macro'. > You wrote you'd rename emacs-eval and emacs-apply. > What are the new names? New primitives will be: lisp-eval, lisp-apply, scheme-eval, scheme-apply New Scheme procedures/macros will be: lisp-true?, lisp-false?, lisp-variable-ref, lisp-variable-set!, import-lisp-function, import-lisp-variable and perhaps: define-global-varialbe, define-command In addition, I could implement import-scheme-procedure or something for Emacs Lisp. Hopefully I am releasing the next version within today. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-15 3:32 ` Keisuke Nishida @ 2000-03-15 5:11 ` Kalle Olavi Niemitalo 2000-03-15 5:43 ` Keisuke Nishida 0 siblings, 1 reply; 15+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-15 5:11 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs Keisuke Nishida <kxn30@po.cwru.edu> writes: > Well, in this way, you can't write this: > > (let ((start (point))) > (save-excursion > (goto-char start))) Why not? It's expanded to: (let ((start (point))) (emacs-eval `(save-excursion (,(lambda () (goto-char start)))))) The lambda form is evaluated in the Scheme side because of the comma, and it captures the current lexical environment like Scheme procedures always do. When Emacs calls the closure, Guile uses the captured binding of start. Or, that's how I think it would work. :-) The Emacs evaluator would have to be changed to call the equivalent of guile-apply if the function being called is a Scheme object. I don't know how difficult that is. If it is too much work, the version with an explicit guile-eval could be used. This is really the only difference between the versions. > OK, I'll try to add the type soon. I guess you can define a new > macro `import-lisp-macro'. That could be used for all the `save-' macros / special forms. But others like `when' and `condition-case' take their parameters in different ways and would have to be handled separately. Perhaps the importing macro should be called `import-lisp-body-macro' because it applies only to macros whose parameters form a single body. Then there could be `import-lisp-1-body-macro' for things like `with-current-buffer' which take one normal parameter and a body. Should I use defmacro instead of syntax-rules? I like syntax-rules more, but it seems slower. How do I define documentation strings for Guile macros? > lisp-variable-ref, lisp-variable-set!, > import-lisp-function, import-lisp-variable Are they used like this? (lisp-variable-set! (import-lisp-variable 'buffer-read-only) 't) I think import-* and export-* names should be used for functions which actually change bindings of symbols, not only return a reference to the variable. `lisp-function' would be enough for that. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-15 5:11 ` Kalle Olavi Niemitalo @ 2000-03-15 5:43 ` Keisuke Nishida 2000-03-15 6:12 ` Kalle Olavi Niemitalo 2000-03-15 11:30 ` special forms (save-excursion) Kalle Olavi Niemitalo 0 siblings, 2 replies; 15+ messages in thread From: Keisuke Nishida @ 2000-03-15 5:43 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > Why not? It's expanded to: > > (let ((start (point))) > (emacs-eval `(save-excursion > (,(lambda () > (goto-char start)))))) Oh, sorry, I was careless. Yes, you are right. If we had Lisp-side Scheme values with some more extensions, it would work. > The Emacs evaluator would have to be changed to call the > equivalent of guile-apply if the function being called is a > Scheme object. I don't know how difficult that is. If it is too > much work, the version with an explicit guile-eval could be used. > This is really the only difference between the versions. Right. I guess it's not very difficult to patch the evaluator, but I would choose the latter since it is easier to implement. We can switch to the other one anytime later on. Could you work on adding the new Lisp type to Emacs? I'm doing other stuff right now. > > OK, I'll try to add the type soon. I guess you can define a new > > macro `import-lisp-macro'. > > That could be used for all the `save-' macros / special forms. > But others like `when' and `condition-case' take their parameters > in different ways and would have to be handled separately. > Perhaps the importing macro should be called > `import-lisp-body-macro' because it applies only to macros whose > parameters form a single body. Then there could be > `import-lisp-1-body-macro' for things like `with-current-buffer' > which take one normal parameter and a body. I see. How about this form? (import-lisp-body-macro save-execution) (import-lisp-body-macro with-current-buffer #t 2) The second argument can be a Scheme name of the macro unless it is #t. The third argument is the number of arguments of the macro (1 is default). > Should I use defmacro instead of syntax-rules? I like > syntax-rules more, but it seems slower. I think faster one is better. This is not a complex syntax and easy to maintain. > How do I define documentation strings for Guile macros? I have no idea yet. We can extend our implementation later on. > > lisp-variable-ref, lisp-variable-set!, > > import-lisp-function, import-lisp-variable > > Are they used like this? > (lisp-variable-set! (import-lisp-variable 'buffer-read-only) 't) Like this: (import-lisp-variable buffer-read-only) (set! (buffer-read-only) t) or (lisp-variable-set! 'buffer-read-only 't) How this looks like? This is my current implementation. ------------------------------------------------------------------------ (define-module (emacs emacs)) (define-public t 't) (define-public nil 'nil) (define-public (lisp-false? sexp) (or (eq? sexp ()) (eq? sexp nil))) (define-public (lisp-true? sexp) (not (lisp-false? sexp))) (define-public (lisp-variable-ref symbol) (lisp-eval symbol)) (define-public (lisp-variable-set! symbol value) (lisp-eval `(setq ,symbol ,value))) (define-macro (import-lisp-variable-1 variable . rest) (let ((name (if (pair? rest) (car rest) variable))) `(define ,name (make-procedure-with-setter (lambda () (lisp-variable-ref ',variable)) (lambda (value) (lisp-variable-set! ',variable value)))))) (define-public import-lisp-variable import-lisp-variable-1) (define-macro (import-lisp-function-1 name) (if (lisp-true? (lisp-apply 'functionp (list name))) `(define ,name (lambda args (lisp-apply ,name args))) (lisp-apply 'error (list "No such function: %s" name)))) (define-public import-lisp-function import-lisp-function-1) ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-15 5:43 ` Keisuke Nishida @ 2000-03-15 6:12 ` Kalle Olavi Niemitalo 2000-03-15 11:37 ` guile-emacs GC (was special forms) Kalle Olavi Niemitalo 2000-03-15 11:30 ` special forms (save-excursion) Kalle Olavi Niemitalo 1 sibling, 1 reply; 15+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-15 6:12 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs Keisuke Nishida <kxn30@po.cwru.edu> writes: > Could you work on adding the new Lisp type to Emacs? Sorry, I have too many projects already. Besides I don't know enough about the Emacs garbage collector. > (import-lisp-body-macro save-execution) > (import-lisp-body-macro with-current-buffer #t 2) > > The second argument can be a Scheme name of the macro unless it is #t. > The third argument is the number of arguments of the macro (1 is default). With a third argument like that, you could take out the "body-". > How this looks like? This is my current implementation. I'll look at it later. ^ permalink raw reply [flat|nested] 15+ messages in thread
* guile-emacs GC (was special forms) 2000-03-15 6:12 ` Kalle Olavi Niemitalo @ 2000-03-15 11:37 ` Kalle Olavi Niemitalo 2000-03-15 12:18 ` Keisuke Nishida 0 siblings, 1 reply; 15+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-15 11:37 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ee.oulu.fi> writes: > Besides I don't know enough about the Emacs garbage collector. The garbage collectors may be a larger problem than I thought... In guileapi.c, you have a list of Emacs Lisp objects which are being used by Guile. This protect_list prevents Emacs from garbage-collecting those objects and anything they point to. It is working fine (although lval_free() may get slow if the list is long). Now, if Emacs Lisp objects can also contain references to Guile objects, there must be a mechanism to prevent Guile from collecting those objects. One could perhaps add a similar list in the Guile side. If something causes a cycle of references between Lisp and Scheme, neither garbage collector can free the data. It's all locked down by the protect lists. To detect the situation, the garbage collectors would have to cooperate. I'm sure that would be a pain to code. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-emacs GC (was special forms) 2000-03-15 11:37 ` guile-emacs GC (was special forms) Kalle Olavi Niemitalo @ 2000-03-15 12:18 ` Keisuke Nishida 2000-03-15 13:48 ` Jim Blandy 0 siblings, 1 reply; 15+ messages in thread From: Keisuke Nishida @ 2000-03-15 12:18 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > If something causes a cycle of references between Lisp and > Scheme, neither garbage collector can free the data. It's all > locked down by the protect lists. To detect the situation, the > garbage collectors would have to cooperate. I'm sure that would > be a pain to code. Oh, we need a meta-GC now :) Seriously, I think we have to make some restrictions on Lisp programs so they don't keep Scheme values. I think people of Guile Emacs do not want to write new programs in Lisp, so it's not a problem. If people of Lisp want to use Guile's features, it is the time to move to the Guile-based Emacs. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-emacs GC (was special forms) 2000-03-15 12:18 ` Keisuke Nishida @ 2000-03-15 13:48 ` Jim Blandy 2000-03-15 15:14 ` Keisuke Nishida 0 siblings, 1 reply; 15+ messages in thread From: Jim Blandy @ 2000-03-15 13:48 UTC (permalink / raw) To: Keisuke Nishida; +Cc: Kalle Olavi Niemitalo, guile-emacs > Seriously, I think we have to make some restrictions on Lisp > programs so they don't keep Scheme values. I think people of > Guile Emacs do not want to write new programs in Lisp, so it's > not a problem. If people of Lisp want to use Guile's features, > it is the time to move to the Guile-based Emacs. Honestly, this doesn't seem like a good idea. There are zillions of useful Emacs Lisp functions that are part of Emacs right now, and it would be a fatal mistake to push a design which doesn't encourage the Lisp and Scheme worlds to share data freely. The best approach is to change Emacs Lisp to use Guile objects. That is, Fcons (if I remember correctly) should call SCM_NEWCELL, and so on. That way, the two languages operate on a common GC, and can share data freely. Ken Raeburn has already done a lot of this work. You really should look at his patches. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-emacs GC (was special forms) 2000-03-15 13:48 ` Jim Blandy @ 2000-03-15 15:14 ` Keisuke Nishida 0 siblings, 0 replies; 15+ messages in thread From: Keisuke Nishida @ 2000-03-15 15:14 UTC (permalink / raw) To: Jim Blandy; +Cc: guile-emacs Jim Blandy <jimb@red-bean.com> writes: > Honestly, this doesn't seem like a good idea. There are zillions of > useful Emacs Lisp functions that are part of Emacs right now, and it > would be a fatal mistake to push a design which doesn't encourage the > Lisp and Scheme worlds to share data freely. > > The best approach is to change Emacs Lisp to use Guile objects. That > is, Fcons (if I remember correctly) should call SCM_NEWCELL, and so > on. That way, the two languages operate on a common GC, and can share > data freely. I know that it is the right way; however, it takes time. People and I do not want to wait that long. See Ken Raeburn's web page. It counts only two hundreds of accesses. Most people are interested in the editor which they CAN use without many problems. I guess that is one reason why many people have not been interested in merging Guile with Emacs. I do not like this situation. I could write a editor that at least worked fine with Guile. And I could advertise it with some interesting facilities such as the GNOME/GTK+ interface. Then, more people will come here (I believe). I do not mean that I am discouraging people from using Scheme data from Lisp programs. I just mean it is not that time. I understand there are so many useful Elisp programs (including mine), so I encourage people to use them from Scheme programs. But the other side is not necessary true at this moment. If there are so many people who want to use Scheme data from Lisp programs, they will do so by replacing the Lisp evaluator with Guile. I just think, that is not my work. > Ken Raeburn has already done a lot of this work. You really should > look at his patches. Yes, I did (about a half year ago), and I appreciate his work. So I am not going to do the same work as his. I intentionally choose a different approach. When more and more people get interested in Guile Emacs, that is the end of my approach and the time to switch to his approach. If there were more people who worked on Guile-based Emacs, I did not need to do this now. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-15 5:43 ` Keisuke Nishida 2000-03-15 6:12 ` Kalle Olavi Niemitalo @ 2000-03-15 11:30 ` Kalle Olavi Niemitalo 2000-03-15 12:42 ` Keisuke Nishida 1 sibling, 1 reply; 15+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-15 11:30 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs Keisuke Nishida <kxn30@po.cwru.edu> writes: > Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > > > Should I use defmacro instead of syntax-rules? I like > > syntax-rules more, but it seems slower. > > I think faster one is better. This is not a complex syntax and > easy to maintain. But the macros made with define-macro (what is the difference between that and defmacro?) are not hygienic by default. Should we hygienize each of them separately, or do we just give people a list of symbols which they must not rebind when using the macros? > (define-public (lisp-false? sexp) (or (eq? sexp ()) (eq? sexp nil))) R5RS doesn't say what () evaluates to, so it would be better to quote it. I believe "sexp" means the usual printed form of an expression. The parameter of lisp-false? is the object itself, not a printed form. Use "obj" instead. > (define-public (lisp-variable-set! symbol value) > (lisp-eval `(setq ,symbol ,value))) The value should be quoted in the setq call. (define-public (lisp-variable-set! symbol value) (lisp-eval `(setq ,symbol ',value))) > (define-macro (import-lisp-variable-1 variable . rest) > (let ((name (if (pair? rest) (car rest) variable))) > `(define ,name (make-procedure-with-setter > (lambda () (lisp-variable-ref ',variable)) > (lambda (value) (lisp-variable-set! ',variable value)))))) > (define-public import-lisp-variable import-lisp-variable-1) Can't you just (export import-lisp-variable-1)? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: special forms (save-excursion) 2000-03-15 11:30 ` special forms (save-excursion) Kalle Olavi Niemitalo @ 2000-03-15 12:42 ` Keisuke Nishida 0 siblings, 0 replies; 15+ messages in thread From: Keisuke Nishida @ 2000-03-15 12:42 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > But the macros made with define-macro (what is the difference > between that and defmacro?) are not hygienic by default. Should > we hygienize each of them separately, or do we just give people a > list of symbols which they must not rebind when using the macros? I don't know either about the difference of those two... Guile provides some procedures like procedure->syntax, so using them might be the best for now. My policy for the moment is, "Anything is OK, as long as it works." We have to be careful choosing API, though. (like import-*) > R5RS doesn't say what () evaluates to, so it would be better to > quote it. > > I believe "sexp" means the usual printed form of an expression. > The parameter of lisp-false? is the object itself, not a printed > form. Use "obj" instead. Right. Thanks. > > (define-public (lisp-variable-set! symbol value) > > (lisp-eval `(setq ,symbol ,value))) > > The value should be quoted in the setq call. There are a lot of bugs in that code... (It doesn't work.) I'll fix them and release the next version soon. > Can't you just (export import-lisp-variable-1)? OK. I didn't know that. Thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2000-03-15 15:14 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-14 12:46 special forms (save-excursion) Kalle Olavi Niemitalo 2000-03-14 13:32 ` Keisuke Nishida 2000-03-14 14:11 ` Keisuke Nishida 2000-03-14 14:17 ` Keisuke Nishida 2000-03-15 0:34 ` Kalle Olavi Niemitalo 2000-03-15 3:32 ` Keisuke Nishida 2000-03-15 5:11 ` Kalle Olavi Niemitalo 2000-03-15 5:43 ` Keisuke Nishida 2000-03-15 6:12 ` Kalle Olavi Niemitalo 2000-03-15 11:37 ` guile-emacs GC (was special forms) Kalle Olavi Niemitalo 2000-03-15 12:18 ` Keisuke Nishida 2000-03-15 13:48 ` Jim Blandy 2000-03-15 15:14 ` Keisuke Nishida 2000-03-15 11:30 ` special forms (save-excursion) Kalle Olavi Niemitalo 2000-03-15 12:42 ` 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).