* guile-emacs-0.1 released @ 2000-03-13 15:11 Keisuke Nishida 2000-03-14 12:46 ` guileapi.x problems [patch] Kalle Olavi Niemitalo 2000-03-15 21:07 ` guile-emacs-0.1 released Ken Raeburn 0 siblings, 2 replies; 14+ messages in thread From: Keisuke Nishida @ 2000-03-13 15:11 UTC (permalink / raw) To: guile, guile-emacs; +Cc: rms Hello, I'm releasing my initial version of Guile Emacs: (May I use this name?) http://gemacs.sourceforge.net/ There is no difference from my previous patch, except this version includes some documentation and should work correctly. I know this version is not very useful yet, but at least it works. I hope this is better than nothing and fun to play around. I'm going to do further work from now so that it becomes better. 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...) Regards, Keisuke Nishida ^ permalink raw reply [flat|nested] 14+ messages in thread
* guileapi.x problems [patch] 2000-03-13 15:11 guile-emacs-0.1 released Keisuke Nishida @ 2000-03-14 12:46 ` Kalle Olavi Niemitalo 2000-03-14 13:20 ` Keisuke Nishida 2000-03-15 21:11 ` Ken Raeburn 2000-03-15 21:07 ` guile-emacs-0.1 released Ken Raeburn 1 sibling, 2 replies; 14+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-14 12:46 UTC (permalink / raw) To: Keisuke Nishida; +Cc: guile-emacs I've spent the evening with guile-emacs-0.1 and it's wonderful! You wrote it needs Emacs 20.6 but version 20.5 seems to work just fine, at least on i486-debian-linux-gnu. (Debian doesn't have 20.6 yet.) There were some problems generating guileapi.x, though: * I was compiling in a separate directory. The makefile tried to find guileapi.c in the build directory. * I have the current Guile headers in ~/include, not /usr/include. Using them requires the -I/home/kalle/include option, which I have in $CPPFLAGS. The snarfing rule didn't use that variable. * When the command failed, a zero-length guileapi.x was left. The first time this happened, I didn't notice and spent some time wondering why emacs-eval didn't work. ================================================================= --- src/Makefile.in.orig Tue Mar 14 14:13:42 2000 +++ src/Makefile.in Tue Mar 14 16:13:15 2000 @@ -1128,8 +1128,14 @@ sunfns.o: sunfns.c buffer.h window.h $(config_h) guileapi.o: guileapi.c guileapi.x +/* Don't leave an empty guileapi.x if guile-snarf fails. + OTOH, guileapi.x must exist when guile-snarf runs. + The -I options are needed for config.h when $(srcdir) is + somewhere else. This can't use $(ALL_CFLAGS) because + guile-snarf may run the preprocessor directly. */ guileapi.x: guileapi.c - guile-snarf guileapi.c > guileapi.x + guile-snarf -I. -I$(srcdir) $(CPPFLAGS) $(srcdir)/guileapi.c > guileapi.x \ + || ( rm guileapi.x; false ) ${libsrc}emacstool: ${libsrc}emacstool.c cd ${libsrc}; ${MAKE} ${MFLAGS} emacstool ================================================================= ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guileapi.x problems [patch] 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 1 sibling, 0 replies; 14+ messages in thread From: Keisuke Nishida @ 2000-03-14 13:20 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > I've spent the evening with guile-emacs-0.1 and it's wonderful! > You wrote it needs Emacs 20.6 but version 20.5 seems to work just > fine, at least on i486-debian-linux-gnu. (Debian doesn't have > 20.6 yet.) I guess my patch might work even with Emacs 19.x :) I just haven't tried it yet. > There were some problems generating guileapi.x, though: Thanks. I'll apply this soon. Probably I should write Makefile more carefully, but I want to write Scheme programs first... Patches are always welcome. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guileapi.x problems [patch] 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 1 sibling, 1 reply; 14+ messages in thread From: Ken Raeburn @ 2000-03-15 21:11 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: Keisuke Nishida, guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > - guile-snarf guileapi.c > guileapi.x > + guile-snarf -I. -I$(srcdir) $(CPPFLAGS) $(srcdir)/guileapi.c > guileapi.x \ > + || ( rm guileapi.x; false ) A suggestion: Redirect output to guileapi.tmp, then rename that file to guileapi.x. Then you're never doing anything to guileapi.x until you've successfully generated the output. Just for paranoia... :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guileapi.x problems [patch] 2000-03-15 21:11 ` Ken Raeburn @ 2000-03-16 4:29 ` Kalle Olavi Niemitalo 2000-03-16 8:55 ` Keisuke Nishida 0 siblings, 1 reply; 14+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-16 4:29 UTC (permalink / raw) To: guile-emacs Ken Raeburn <raeburn@raeburn.org> writes: > A suggestion: Redirect output to guileapi.tmp, then rename that file > to guileapi.x. That is what I tried initially, but it didn't work. guileapi.c #includes guileapi.x and if it doesn't exist, guile-snarf complains. Perhaps the #include should be wrapped in #ifndef SCM_MAGIC_SNARFER. Is guile-snarf guaranteed to keep defining that? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guileapi.x problems [patch] 2000-03-16 4:29 ` Kalle Olavi Niemitalo @ 2000-03-16 8:55 ` Keisuke Nishida 2000-03-16 16:57 ` Kalle Olavi Niemitalo 0 siblings, 1 reply; 14+ messages in thread From: Keisuke Nishida @ 2000-03-16 8:55 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > > A suggestion: Redirect output to guileapi.tmp, then rename that file > > to guileapi.x. > > That is what I tried initially, but it didn't work. guileapi.c > #includes guileapi.x and if it doesn't exist, guile-snarf complains. > > Perhaps the #include should be wrapped in #ifndef SCM_MAGIC_SNARFER. > Is guile-snarf guaranteed to keep defining that? This is what guile-snarf does: ## We must use a temporary file here, instead of a pipe, because we ## need to know if CPP exits with a non-zero status. ${CPP} -DSCM_MAGIC_SNARFER "$@" > ${temp} || exit $? And this is how Guile's Makefile call it: .c.x: PATH=.:${PATH} ./guile-doc-snarf $< $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $< > $@ \ || { rm $@; false; } What would be the best? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guileapi.x problems [patch] 2000-03-16 8:55 ` Keisuke Nishida @ 2000-03-16 16:57 ` Kalle Olavi Niemitalo 2000-03-17 9:55 ` Keisuke Nishida 0 siblings, 1 reply; 14+ messages in thread From: Kalle Olavi Niemitalo @ 2000-03-16 16:57 UTC (permalink / raw) To: guile-emacs Keisuke Nishida <kxn30@po.cwru.edu> writes: > What would be the best? I think it would be cleanest to put #ifndef SCM_MAGIC_SNARFER around the #include: we don't want the behavior of guile-snarf to depend on the previous contents of *.x. After this, the Makefile could be changed to use a temporary file. Although the current version of guile-snarf defines SCM_MAGIC_SNARFER, that macro doesn't seem to be documented anywhere so relying on it is a bit risky. If the Guile team promises they won't remove this macro, all is well. Such a promise should be written down in the manual so that their grandchildren won't forget it. ;-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guileapi.x problems [patch] 2000-03-16 16:57 ` Kalle Olavi Niemitalo @ 2000-03-17 9:55 ` Keisuke Nishida 0 siblings, 0 replies; 14+ messages in thread From: Keisuke Nishida @ 2000-03-17 9:55 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes: > I think it would be cleanest to put #ifndef SCM_MAGIC_SNARFER > around the #include: we don't want the behavior of guile-snarf to > depend on the previous contents of *.x. After this, the Makefile > could be changed to use a temporary file. Do you know why the Guile team doesn't do that? We might better ask them before making this change. > Although the current version of guile-snarf defines > SCM_MAGIC_SNARFER, that macro doesn't seem to be documented > anywhere so relying on it is a bit risky. If the Guile team > promises they won't remove this macro, all is well. Such a > promise should be written down in the manual so that their > grandchildren won't forget it. ;-) I believe they won't :) But you could suggest them to do so. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guile-emacs-0.1 released 2000-03-13 15:11 guile-emacs-0.1 released Keisuke Nishida 2000-03-14 12:46 ` guileapi.x problems [patch] Kalle Olavi Niemitalo @ 2000-03-15 21:07 ` Ken Raeburn 2000-03-16 12:29 ` Keisuke Nishida 2000-03-16 18:50 ` Richard Stallman 1 sibling, 2 replies; 14+ messages in thread From: Ken Raeburn @ 2000-03-15 21:07 UTC (permalink / raw) To: Keisuke Nishida; +Cc: rms 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guile-emacs-0.1 released 2000-03-15 21:07 ` guile-emacs-0.1 released Ken Raeburn @ 2000-03-16 12:29 ` Keisuke Nishida 2000-03-16 18:50 ` Richard Stallman 1 sibling, 0 replies; 14+ messages in thread From: Keisuke Nishida @ 2000-03-16 12:29 UTC (permalink / raw) To: Ken Raeburn; +Cc: guile-emacs Ken Raeburn <raeburn@raeburn.org> 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.... After all, do you think my project can use this list? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guile-emacs-0.1 released 2000-03-15 21:07 ` guile-emacs-0.1 released Ken Raeburn 2000-03-16 12:29 ` Keisuke Nishida @ 2000-03-16 18:50 ` Richard Stallman 2000-03-17 2:10 ` Ken Raeburn 1 sibling, 1 reply; 14+ messages in thread From: Richard Stallman @ 2000-03-16 18:50 UTC (permalink / raw) To: raeburn; +Cc: kxn30, guile-emacs 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. I don't think so. That is not a useful behavior in the context of Emacs. To get useful results, we need to make the normal ways of writing code access the local bindings of Emacs. And then there's variables restricted to specific types, and with side-effects in the C code. These variables are just an implementation method, not a feature users depend on. I'm sure we could manage to implement the code that uses these variables in some other way, if that will simplify matters by avoiding the need for a special feature for such variables. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guile-emacs-0.1 released 2000-03-16 18:50 ` Richard Stallman @ 2000-03-17 2:10 ` Ken Raeburn 2001-01-07 9:13 ` Richard Stallman 0 siblings, 1 reply; 14+ messages in thread From: Ken Raeburn @ 2000-03-17 2:10 UTC (permalink / raw) To: rms; +Cc: guile-emacs Richard Stallman <rms@gnu.org> writes: > 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. > > I don't think so. That is not a useful behavior in the context of > Emacs. To get useful results, we need to make the normal ways of > writing code access the local bindings of Emacs. Which "normal ways of writing code"? If people want to write elisp, it'll work just fine, with the expected dynamic bindings and buffer-local variables and so on. If people want to write Scheme to extend an application -- be it GNU Emacs or GNU ld or whatever -- I think it should be Scheme, not "Scheme except maybe for dynamic bindings if you're running Emacs". Otherwise, what's the point of a supposedly common extension language for different applications? You wind up writing Scheme libraries that'll work in lots of GNU applications except Emacs, or they'll work only in Emacs.... IMHO, the right way to go is to allow both Scheme and Lisp programming, with each one looking like its "normal" self, and odd things happening only when you cross the boundaries. We should keep that as clean and easy to use as possible, of course, but I think that's the place where any weirdness should be, and I fully expect it'll be impossible *not* to have at least a little weirdness (e.g., the whole ()/#f/nil problem, and function slots that are part of elisp but not scheme). I think Keisuke's got the right idea -- simple functions available in each language to manipulate what's on the other side of the split between languages. > And then there's variables restricted to specific types, and with > side-effects in the C code. > > These variables are just an implementation method, not a feature users > depend on. I'm sure we could manage to implement the code that uses > these variables in some other way, if that will simplify matters by > avoiding the need for a special feature for such variables. I don't think they'd be hard to do, given the rest, they're just things to keep in mind when figuring out how to do the rest. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guile-emacs-0.1 released 2000-03-17 2:10 ` Ken Raeburn @ 2001-01-07 9:13 ` Richard Stallman 2001-01-07 13:28 ` Ken Raeburn 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2001-01-07 9:13 UTC (permalink / raw) To: raeburn; +Cc: guile-emacs I am responding to messages that got buried during the year. Please forgive me for taking so long to respond. You wrote: > 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. I responded: > I don't think so. That is not a useful behavior in the context of > Emacs. To get useful results, we need to make the normal ways of > writing code access the local bindings of Emacs. You responded: Which "normal ways of writing code"? It occurs to me now that there's more than one way of interpreting what you originally said. So I think the useful thing for me to do is explain what I'm concerned about. If people want to write elisp, it'll work just fine, with the expected dynamic bindings and buffer-local variables and so on. If people want to write Scheme to extend an application -- be it GNU Emacs or GNU ld or whatever -- I think it should be Scheme, not "Scheme except maybe for dynamic bindings if you're running Emacs". The Scheme language certainly should not be changed, so variables should ordinarily be lexical as usual in Scheme. And these lexical variables would have nothing to do with Emacs buffer-local bindings. But whatever mechanism people use in Scheme to make and access dynamically scoped variables, it should be integrated smoothly with Emacs buffer-local and frame-local bindings when you use it in Emacs. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: guile-emacs-0.1 released 2001-01-07 9:13 ` Richard Stallman @ 2001-01-07 13:28 ` Ken Raeburn 0 siblings, 0 replies; 14+ messages in thread From: Ken Raeburn @ 2001-01-07 13:28 UTC (permalink / raw) To: rms; +Cc: guile-emacs > I am responding to messages that got buried during the year. > Please forgive me for taking so long to respond. It's okay, I know the problem too well.... > It occurs to me now that there's more than one way of interpreting > what you originally said. So I think the useful thing for me to do > is explain what I'm concerned about. Sorry I wasn't more clear about it. Yes, what you describe is what I want to see. What I meant by "interaction of Lisp dynamic bindings...and Scheme lexical bindings" was basically how to set up that interface for Scheme code to access the "current" elisp values, and possibly the reverse. (And the function value of a symbol, etc.) > But whatever mechanism people use in Scheme to make and access > dynamically scoped variables, it should be integrated smoothly with > Emacs buffer-local and frame-local bindings when you use it in Emacs. Yes, the Emacs "current" value would deal with not just the dynamic binding, but also the buffer- and frame-local bindings, falling back to the global Scheme "default" value only if none of the others were in use. Though it may be useful to provide functions to look at each of those separately, for maximum convenience we probably want one or two macros for reading and writing that will just Do The Right Thing for people manipulating the elisp environment from Scheme. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2001-01-07 13:28 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-13 15:11 guile-emacs-0.1 released 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 ` guile-emacs-0.1 released Ken Raeburn 2000-03-16 12:29 ` 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
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).