Re: [Bug-zile] Incremental search is dog slow in moderately-sized files

[Reuben Thomas]

On 20 January 2014 23:20, Gary V. Vaughan <address@hidden> wrote:

I spotted many of those fixes in the gitlog.  However, since there is no 0-based indexing anywhere in Lua Zile, I guess these are purely artifacts of the C->Lua transition, right?

Right: I tried to transition from 0 to 1-based indexing too.

 And yet there's a ton of +1 and -1 adjustments scattered around that I don't fully understand yet. Or are Zile buffers 0-based, and have to be adjusted to Lua 1-based indices?

No, I made buffers 1-based too. The proof of this is in get_buffer_size, which adds 1 to the size of the buffer (including window) to make it an offset, the subtracts one from the offset to the end of the buffer to get a size. (Incidentally, I suspect this is where a lot of the ±1 comes from: converting between 1-based offsets and lengths. This is the point at which any fundamentalist 0-basers will start muttering into their beards. (Icon string indexing solves this argument for strings, as its indexes go *between* characters; however, that doesn't help when you're trying to think about arrays, when you're most definitely pointing *at* an element.)

 

 If so, then I might try and go for a clean slate by making everything 1-based, except when accepting or displaying buffer indices in the zlisp Defuns...

Probably right, but this is definitely a big problem with implementing Zile in Lua, and in general, in doing impedance matching between Lua and C. I don't think the Lua team admit to any regrets on this score, but I think they should!

--
http://rrt.sc3d.org