[slim-vim] some comments on ecl-slime, and Vim+ECL in general

[Brad Beveridge]

On 6/9/06, Larry Clapp <larry at theclapp.org> wrote:
> Brad,
>
> A couple of things:
>
> o I pulled the repository for ecl-slime.  It's missing two files:
>   interface.lisp and impl-ecl.lisp.
Opps, my bad.  I've pushed them to the repo now.

> o I've patched ecl-slime.lisp a bit to use some vim: functions.  I'll
>   email you the patch separately.
> o I noticed that in ecl-slime and ecl-repl we do similar things with
>   Lisp forms in a Vim buffer (e.g. grab the current form, grab the
>   top-level form, etc).  I propose that I pull out the common stuff
>   and put it in a separate library.  Whatcha think?
I fully agree.

>
> Everyone,
>
> o What do you think about using some Emacs names for analogous
>   functionality?  e.g. (point) to get the current cursor position;
>   (save-excursion ...) to save the cursor position, run some code, and
>   restore the cursor position; and so forth?  It would allow us to
>   piggy-back on the design and documentation of Emacs (and maybe make
>   it easier and more attractive for Emacs hackers to use Vim+ECL).  On
>   the other hand, it might give Emacs hackers hacking Vim a false
>   sense of security -- maybe we should make a clean break?
I'm not sure either way here.  I've tried to mimic the Slime function
names, but that is a pretty obvious choice.  I suspect that it is
probably best to not mimic Emacs, because we simply will not get the
semantics exactly right.  For things that really have no current name
in Vim, like save-excursion, then I think choosing the Emacs names
makes sense.

> o Now that we have Vim7, and a small-but-usable (and easily
>   expandable) Vim FFI, maybe we should consider making small posts in
>   comp.editors and comp.emacs?  Speaking only for myself (and who else
>   would I speak for? ;), my goals have expanded from "Slime for Vim"
>   to "doing as much of my Vim customization & scripting in Lisp as
>   possible".  Emacs people (some of them) have long wanted an
>   Emacs-in-CL, and an Emacs-in-native-code (as opposed to
>   byte-compiled Elisp).  We have the seeds for both.
I wouldn't mind this happening.  I would expecially like it if some
Vim guru had time to look at the async part of the patch and could fix
the bug I am seeing in the console with socket callbacks.

Cheers
Brad