[slim-vim] Vim+ECL patch

[Larry Clapp]

On Mon, May 22, 2006 at 07:56:10AM -0700, Brad Beveridge wrote:
> > In the long term ... I'm not sure what I'd prefer.  Part of me
> > says "make all C Vim functions continue to take 1..n+1, and change
> > all Lisp Vim functions to take 0..n, and make the Lisp functions
> > translate to the C functions' expected coordinate scheme".  But
> > the other part of me says "change all C Lisp interface functions
> > to take 0..n, and have them translate to other Vim functions'
> > expected coordinate scheme".
> >
> > The first option keeps all C functions (both normal Vim functions
> > and Lisp-interface "internal" functions) using the same coordinate
> > scheme, but makes all Lisp functions that talk to them have to do
> > 1- and 1+ all over the place (or call some "fix-it" function on
> > their coordinates first, or something).  The second option makes
> > the Lisp functions easier, but makes the C functions have to do
> > the same translations, and makes them inconsistent with the rest
> > of Vim.
> >
> > Thoughts, anyone?
> 
> I agree that we need to be consistant.  I think that I would prefer
> the Lisp code to access lines on a 1..n basis.  To append a line,
> you replace-line and n+1.  I _think_ that is consistant with
> internal Vim, which is probably a good thing.

It is consistent with internal Vim, but I don't consider it a good
thing.  I want to be able to make a very easy choice when doing
Vim+ECL programming: If I'm writing in Lisp, I know I use zero-based
code (buffer numbers, lines, etc); if I'm writing in C, I'll use
whatever Vim internals already do.

So I guess I'd rather the C internal "FFI" take zero-based indexes and
translate them as appropriate.  When we write Lisp code that calls Vim
functions (e.g. append() / bufnr() / col(), etc), have them do the
same thing: accept zero-based indexes and translate to one-based
indexes when calling Vim functions and translate their return values
back to zero-based values.

I'm imagining years in the future when we have way more Lisp code for
Vim.  I don't want to have to know that THIS function eventually calls
bufnr() and so I have to use 1..N for its ranges, but THAT function
doesn't and so I use 0..(N-1), and oh if I want to use BOTH of them
then I have to remember all this and translate the indexes myself,
over and over and over, squared and cubed.  Ick ick ick!

A simple example: Say I have an array that stores information indexed
by the buffer number.  I have 5 buffers.  I can either waste an array
slot and alocate one more than I need (0..5) and use aref directly

  (defun number-of (b) 
    (vim:vim-funcall "bufnr" b))
  (setf foo (make-array 6))
  (aref foo (number-of some-buffer))

or I can manually translate from one coordinate system to the other:

  (defun number-of (b) 
    (vim:vim-funcall "bufnr" b))
  (setf foo (make-array 5))
  (aref foo (1- (number-of some-buffer)))

OR (best case) number-of can be smart and do the 1- all on its own:

  (defun number-of (b) 
    (1- (vim:vim-funcall "bufnr" b)))
  (setf foo (make-array 5))
  (aref foo (number-of some-buffer))

and that's that.

> To be honest, I didn't think too hard about this when I "fixed" it.
> At the moment there is only a small part of my code (the Gray stream
> to a buffer) that uses this.  I changed the Gray stream
> implementation from calling a Vim script to append to the buffer to
> using pure Lisp - it sped the stream up a lot.  I was doing this to
> try to avoid the bug where the input listener crashes after a while.
> It didn't fix it :)

Bummer.

> So unless somebody makes the Vim ECL buffer handling consistant
> today, I will probably do that tonight.  Gotta do something other
> than bang my head against this input listener bug.

Okay.  Keep us updated.

-- Larry