[slimpl] some comments about vim internals

[Larry Clapp]

On Sun, Mar 05, 2006 at 07:41:01PM -0800, Brad Beveridge wrote:
> On 3/5/06, Larry Clapp <larry at theclapp.org> wrote:
> >   Emacs
> >     <-> presentation layer (Elisp)
> >       <-> backend interface (Elisp)
> >         <-> backend implementation (Elisp/CL)
> >           <-> swank (CL)
> >
> >   Vim
> >     <-> presentation layer (Vim+ECL)
> >       <-> backend interface (ECL)
> >         <-> backend implementation (Elisp/CL)
> >           <-> swank (CL)
> The above scenario is precisely what I think.  Except I'm not sure
> about the backend implementation needing to run on both Elisp and CL
> - are we unnecessarily limiting ourselves by using Elisp?  And what
> do we really gain?

"Limiting ourselves"?  Yes.  "Unnecessarily"?  No.  :)  "What do we
gain"?  Retention and reuse of most of Slime.

The above outlines not only where I think *we* should go, but also
where we should suggest *slime* go.  This design neatly abstracts and
compartmentalizes (dare I say, encapsulates :) the various layers of
functionality, and lets the above and below layers vary pretty much as
they like.

Slime already has a great deal of flexibility and robustness; this
gives it more of both, and more mobility to boot.

> The way I am tackling the "rewrite" right now is to cut and paste
> slime functions and rename to ooze as I go, that way I am forced to
> read the code and make sure I think it will sort of work, rather
> than having a bit of code that behaves slightly differently in CL
> than in its native CL environment.

Excellent idea.  I would add, eyeballs are good, but code is better.
When the time comes to solidify your assumptions and make your mental
test cases more concrete, take a look at xlunit
(http://www.cliki.net/xlunit).

> > The backend would compile in both Elisp and CL.  It would probably
> > have three sub-parts: a common part, some CL->Elisp glue that let
> > the common part run on Elisp, and some Elisp->CL glue that let the
> > common part run on CL.  (Does Elisp have #+ and #-?)
> I imagine that right now I am not diverging too far from vanilla
> Elisp, so maybe the common part could be written in plain Elisp &
> just create some Elisp -> CL glue where needed?

Quite possibly.  I don't know Elisp, so I left some wiggle room in the
design.  :)

> > ... And now I'd like to comment on my comment  :)  with an excerpt
> > from http://www.objectmentor.com/publications/dip.pdf:
> >
> > > The Definition of a "Bad Design"
> <SNIP>
<snip>
> The problem with OSS projects is that you have a bunch of people
> wanting to help, but until someone makes something that kinda works,
> it is hard to get everyone moving in the same direction.

Yes, that's why I waited 'til I had something fairly concrete for
Slimpl before I released anything.  ESR has noted the same thing.

> I don't know that I can, or want to be, the guy that gets the
> skeleton built.  I'm going to keep tracking ahead with ooze (feel
> free to take the name if you like it :),

Maybe.  We should worry more about design and code right now than
about names.  :)

... That said, I still like Slim-Vim, and see no reason to change it
just because the implementation language has changed.  Obviously
"slimpl" doesn't really apply any more, if we want a special name just
for the interface layer.  I dunno; long term, I doubt the Slimers will
want to change the name of their project (and why would they?), and so
when/if we integrate with them, we'll probably have to just go with
"Slim-Vim, a sub-project of Slime".  :)  I don't care, I just want to
use Vim to do Lisp.  (And now, use Lisp to do Vim, too!  WooHoo!)

> but I frankly don't expect to be the first person to get code that
> we can gather around.
> 
> So, although I am doing _something_ useful, I want other people to
> do more useful stuff :)

Cool.  Some things I think we need (for interested bystanders):

  - A survey of Slime, with some notations of what functions or sets
    of functions do, and how much they directly interact with Emacs
    (creating buffers, reading input, etc).

  - Documentation and help files for Jim Bailey's ECL interface.
    if_ecl.c in Jim's patch is less than 600 lines of well written C.

    Jim made it very easy to follow the code.  For example, to find
    out what #'window-cursor does, start at the top and see that the
    VIM package exports the WINDOW-CURSOR symbol.  Search forward to
    find that the WINDOW-CURSOR function does nothing but call
    WINDOW-CURSOR-INT.  Search forward for WINDOW-CURSOR-INT to find
    that it's an ECL foreign function aliased to the C function
    cl_vim_window_cursor_int.  Search backwards to find that
    cl_vim_window_cursor_int returns a cons of the cursor's line and
    column number.  (Once you set Vim's "iskeyword" flag to include
    dashes (":set iskeyword+=-"), you can do most of this navigation
    with the # and * keys.  I found the C definition of #'command in 7
    keystrokes (not counting shift keys).  Or you could just trust the
    naming scheme and search directly for "cl_vim_command_int" -- and
    you'd be right.  My point is, it's easy.  Thanks, Jim!)

  - Somebody do a headlong rush at Slime.el and see how much compiles
    unchanged in CL.  (Brad's looking at this already.  Thanks, Brad!)

  - Nothing else comes to mind, but I'm sure I'll think of ten others
    as soon as I hit "send" on this email.  :)

I wondered for a moment if we should ping the Slime team about some of
this, but decided we should probably wait until we have some actual
code to show them.  That will give us credibility and probably help us
refine our proposal anyway.

-- Larry