[slim-vim] thanks, feedback

[Brad Beveridge]

On 11/08/06, Tomas Zellerin <zellerin at gmail.com> wrote:
> 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?

Yes it is.  Does anybody think that we are violating any licenses
here?  I'm not a lawyer, but I am pretty certain we are OK.

Cheers
Brad