[slim-vim] REPL and debugging

[Larry Clapp]

On Tue, Mar 21, 2006 at 01:10:45PM +0000, Jim Bailey wrote:
> On Mon, 20 Mar 2006 22:19:10 -0500
> Larry Clapp <larry at theclapp.org> wrote:
> <snip>
> > > It is a shame about the debugger not being able to recursive
> > > edit because vim has no support.
> > 
> > Yeah.  I've taken a look at the main_loop function, and it seems
> > to use global variables just out the wazoo.  Maybe we could create
> > a struct, put all the globals in it, and change all the global
> > accesses to use access functions instead, which would look at
> > whatever struct was active.  Look, ma, dynamic variables!
> > Greenspunning at its finest.  But hey, it might work.
> 
> I have though of a way to add recursive edit-style debugging. Since
> vim isn't expecting to be used that way (mmmmmm globals), and ecl
> uses c's stack so call-with-current-continuation can't be added
> easily, we could just go mad and use our very own separate stack for
> ecl, like the one you get free with every thread.

Yeah, I thought of threads, too, but had no idea how to start using
them, or whether they worked portably even on just Windows/Linux/Mac.
By all means, look at threads.

> The only problems I see with this is that not all platforms have
> threads, and I don't like using threads if it all possible. It would
> certainly be a shame to mandate threads for any use of vim+ecl, so
> as long as it is only used when really needed, like for a really
> nice REPL, and slim-vim windows then its probably a good thing to go
> this route rather than sacrifice functionality.

Actually, I don't think you'd need threads for slim-vim, i.e. talking
to Swank over a socket.  Slime handles most of the Swank interaction
with a simple event loop.

> I am still going to add type checking before I do anything else, but
> then I will take a look into threading, and locking and all that
> good stuff.

Cool.  If you have a minute, also take a look at the changes for Vim7;
maybe they changed enough to make recursive editing easier.  For
example, one of the features high on the voting list is multiple
top-level Vim windows.  I think that'd require something very similar
to recursive editing, i.e. multiple copies of main_loop running
around.

> > Interesting.  You translated the Vim verbatim.  We should look at
> > whether Vim actually sets VIMRUNTIME in the C environment area,
> > and use that if it exists.
> 
> Going the direct route is nice and everything, but I hadn't had a
> chance to code for so long I just had to write an s-expression :)

:)  For the record, I meant no offense, it just struck me funny.  :)

-- L