[slim-vim] thanks, feedback

[Tomas Zellerin]

On 8/11/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 11/08/06, Serafeim Zanikolas <serzan at hellug.gr> wrote:
> > Στις Friday 11 August 2006 13:25, ο/η Larry Clapp έγραψε:
> > > <leader>x is the Slim-vim command and talks to the remote Lisp, and
> > > doesn't update the --lisp-repl-output-- buffer. <leader>ee is the
> > > ecl-repl command and talks to the embedded Lisp, and updates the
> > > --lisp-repl-output-- buffer.
> >
> > This may sound naive but I can't help asking: why is there a need for both an
> > embedded lisp and a remote lisp? Is it possible to use only the embedded
> > lisp? (I see that the bindings currently get setup only after connecting to
> > swank)
> >
>
> Good question.  Originally, the goal of the project was to replicate
> Slime in Vim - ie access the remote Lisp.  We started off using Perl
> to handle the sockets.  Then Jim Bailey got ECL into Vim and we had an
> embedded Lisp in Vim.  There is no reason why you can't use Vim+ECL to
> do basic Lisp tasks, but there are some disadvantages
>  - Vim+ECL is single threaded, if you have a long running Lisp task
> your editor doesn't work.
>  - You don't get the fancy debugger facilites that Slim-vim/Slim give you.
>  - Standard io goes to Vim buffers (in a way that we just found out is
> very slow)
>
> But, for at least learning Lisp, using the embedded ECL is probably fine.
>
> Cheers
> Brad

Other answer may be: different lisp implementations have different
strengths. You should use one (e.g., sbcl) if you need speed of
compiled application, other (e.g., clisp) if you want to just make
quite small stand-alone executable, and whichever one you are best
accustomed to in general (if it is ecl, good for you in the vim :) ).

Other issues may include different bundled add-ons and features
(threading was already mentioned; ffi may be other) and license - ecl
is LGPL, isn't it?

Using the interface like this lets you choose the implementation you prefer.

Regards,

Tomas