public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
* 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: 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: 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: 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: 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: 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: 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-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).