From: "Gray, Jeff" Date: 2002-06-28T08:42:48+09:00 Subject: RE: Gvim interface to the ruby debugger? Ned Konz [ned@bike-nomad.com] wrote: > I've been thinking about this (for both Ruby and Perl). The main > problem is that you have to have an external connection to the > debugger [...] Yes, this was the biggest obstacle I saw when I first tried to envision how such a system would work. Since Vim is not a shell and will never be, and AFAIK can only execute shell commands in "batch mode" (open a shell and wait for the command to terminate), it seemed at first that you'd need a one-shot script that takes a command from Vim, connects to a running debug server through a socket (starting the server which in turn starts the debugger if there isn't one running), executes the command, and returns the results back to Vim. Kinda convoluted. Someone here suggested using an expect script as the interface, but I wanted to keep the solution confined to Ruby and Vim. > The built-in debugger interface is pretty specialized, and hooks into > the main event loop of Vim (and only works with X). Agreed. I didn't even know Vim had a debugger interface until I did a Google search on "Vim Ruby debugger" and was directed to one of the Vim help pages. But in doing so I found the VIM Ruby module; so now my current thinking is a central debug server that forks off a Gvim window on one side as a client and a debug session on the other. This means you can't start it from inside an existing Gvim window, but that's acceptable to me. > I don't know if you want this to work under Windows It's not my main platform, but yes. > but it's possible > (I think) to use named pipes in both the Unix and Windows envronment > (at least Windows/NT; don't know if you can do this with > DOS-windows). > > So you could whip up a version of debug.rb that talks to a couple of > named pipes, and then open a connection to those pipes from Vim. Can you talk to an open pair of pipes from Vim? I didn't think you could keep a live connection to another process in Vim in this way, hence my convoluted socket-based architecture. Thanks for the suggestions, - jeff