Re: emacs, guile, and the manual

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> Hey folks,
>
> Happy birthday Jao, and happy summering Neil, hope things are going
> well. I have a bug for you two :)

Hi Andy,

> I have been poking the manual in the section "Using Guile Interactvely",
> in scheme-using.texi. I almost have the description of the REPL and the
> debugger updated to reflect the current state of things, at which point
> I will breathe a sigh of relief and promptly forget about things -- that
> is, if we can decide on what to do about "Using Guile in Emacs".
>
> That section has some excellent documentation for GDS. However, I don't
> think GDS works with Guile 2.0, but Geiser does. What should we do to
> fix the emacs and guile situation?

In general, if any doc is now wrong (in 2.0), surely it must be
removed.  If part of your concern here is about offending me - please
don't worry about that, I won't be offended!

Right now GDS doesn't work, so I think we have to discount it.  If it
was ever resurrected, the doc (to the extent still appropriate) could of
course be resurrected too, from Git.

Jao said he wanted to work on some manual doc for Geiser - I wonder how
that is going?

> I would be OK with excising GDS and its docs, and having the manual
> endorse Geiser, *IF* someone (Jao?) takes a close look at GDS docs and
> code, takes notes on what's useful, and replicates those bits of
> functionality in Geiser.

Agreed, and I imagine that's not too far in practice from what Jao was
already planning.

> In particular I would be happy if I could connect to a TCP port running
> on an application from Emacs (not requiring stdin to be the repl). I
> suppose that port could just be running a new REPL on a telnet, which
> does have the advantage that you can connect to it with plain comint.
>
> The debugging integration could probably wait, as debugging VM programs
> is still in flux, I think.

When debugging integration is (at some future time) included, I think
the application<->debugger channel will need to be more complex than a
normal REPL - for example, so that there is a way for the application to
tell the debugger when a breakpoint has been hit (on some thread other
than the TCP port thread).  Therefore it may not be wise to begin with a
REPL implementation now.

On the other hand, a REPL is fine for things like help, introspection
and evaluation (and tracing, if asynchronous trace output doesn't get
mixed up with other REPL output), so if it's really easy to implement a
REPL-based channel, probably that is worth doing in the interim after
all (until VM debugging crystallises).

Regards,
      Neil