> Well, what do you want to do?
>
> You have access to the windows, to the buffers, and to the contents of the
> buffers. As well, you have access to the Vim variables that affect the
> behavior of the editor.
>
> Beyond this, you can use the standard Vim mapping, etc. to "glue" Ruby to
> keystrokes and events (like starting to edit a buffer, for instance).
>
> And the state of the Ruby interpreter seems to persist, so you can (for
> instance) set globals and expect them to remain set.
>
> You can change settings in the editor from Ruby by using VIM::set_option()
or
> VIM::evaluate() (with side effects). And you can run arbitrary editor
> commands with VIM::command().
>
> You can edit text in the buffers as needed.
>
> You can load external Ruby files.
>
> So pretty much anything that you want to do, you can do (as far as I can
> tell). For instance, you could make an interactive development environment
by
> tying into the debugger and/or irb via named pipes. Then you could map vi
> keystrokes to commands for the debugger.
>
> --
> Ned Konz
> currently: Stanwood, WA
> email:     ned / bike-nomad.com
> homepage:  http://bike-nomad.com
>

Well I just sent a bug report to vim-dev because I found that one of the
things you
can't do is define a vim function from perl, the reason is a little
technical but it should
also apply to ruby if I understand the code correctly.   Basically the
problem is that to
define a function you need to use a command but a special multiline one.
The VIM::command() function will only execute simple commands, any multiline
command
will triger a prompt at the vim command line for the next line and will
ignore the rest of the
string (possibly multilined) passed to it.  I'm awaiting the answer from
Bram Molenaar on
this.
Benoit