[slim-vim] Vim+ECL patch

[Larry Clapp]

On Sun, May 21, 2006 at 10:51:02AM -0700, Brad Beveridge wrote:
> Hi all, I wanted to try to create a proper darcs patch of this, but
> couldn't remember how I had ./configured my Vim+ECL+Async stuff &
> couldn't be bothered figuring it out right now.
> vim-buffer-lines will not get the last line in a buffer, the code
> should be like the following.
> 
> Cheers
> Brad
> 
> static cl_object cl_vim_buffer_lines_int(cl_object buf_, cl_object
> start_, cl_object end_)
> {
>     buf_T *buf = ((buf_T *)ecl_foreign_data_pointer_safe(buf_));
>     int start = fix(start_);
>     int end = fix(end_);
>     cl_object result = Cnil;
> 
>     while (end >= start)
>     {
>         result = make_cons(make_string_copy(ml_get_buf(buf, end--, FALSE)),
>                            result);
>     }
> 
>     return result;
> }

This fixes the specified bug ("vim-buffer-lines will not get the last
line in a buffer") but makes vim:buffer-lines inconsistent with
replace-lines.  Without your change, buffer-lines and replace-lines
both took a range of 1 .. (1+ (buffer-line-count buffer)).  With this
change, buffer-lines takes 1 .. (buffer-line-count buffer) and
replace-lines takes 1 .. (1+ (buffer-line-count buffer)).

The range 1 .. (1+ (buffer-line-count buffer)) is (sort of) consistent
with other CL array functions, with the exception that Vim indexes
buffer lines starting at 1, whereas CL indexes arrays starting at 0.
So where a CL function takes 0..n, Vim functions take 1..n+1.
buffer-lines and replace-lines were consistent with that numbering
scheme.

In the short term, I'd prefer a different approach to fixing the
buffer-lines bug:

 (defun buffer-lines (&key (buffer (current-buffer))
-                         (start 1) (end (buffer-line-count buffer)))
+                         (start 1) (end (1+ (buffer-line-count buffer))))
   "returns the lines from :start to :end in :buffer (defaults to
   (current-buffer))"
   (buffer-lines-int buffer start end))

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?

-- Larry