Lua Plugin API

[Josh Wainwright]

Some issues/inconsistencies in the current state of the lua API.

• inconsistency in cursor positioning:
  • cursor:to(line,col) should imply cursor.line == line and cursor.col == col
• handling of invalid positions: negative or beyond EOF
  • The following functions should handle input values, n of n <= 0 and n > size of file.
  • cursor:to()
  • file:content()
  • file:delete()
  • file:insert()
  • A possible suggestion:
    • n>0: use value of n as expected
    • n<=0: use position of current primary cursor, similar to using '.' in vim.
• Cursor positions should be consistent -- is (0,0) the first character in the file, or (1,1)?

I'll add any more here that I come across while testing. Feel free to ignore any points that are dumb or obvious that I haven't thought properly about. vis is already a really solid editor, its acting as my daily driver for most of my editing needs, just looking to improve further :)

[Josh Wainwright]

The values provided by vis.win.file.lines[] depends on the cursor position.

When retreiving the same line as the cursor is on, then only the text underneith and after the cursor is available. For other lines, the whole line is available. eg win.file.lines[win.cursor.line] always displays the content of the current line after the cursor, not the whole line.

[Marc André Tanner]

The values provided by vis.win.file.lines[] depends on the cursor position.

This should be fixed by e399562

Cursor positions should be consistent

The intention is that all byte values (like cursor.pos) are 0-based while all line and column numbers are 1-based. That is (cursor.line, cursor.col) should yield (1,1) at the beginning of the file. Isn't this already the case?

[Josh Wainwright]

This should be fixed by e399562

Great 👍. Thanks

byte values (like cursor.pos) are 0-based while all line and column numbers are 1-based

That sounds very sensible. I came across an error, rather than incosistancy (I think). When using win.cursor:to() with values larger than the file, then the values reported by win.cursor.{line,col} are reasonable~~[1]~~, but win.cursor.pos is not set (4294967295 seems like a MAX_INT).

[1]: Reasonable in that the values are both inside the limits of the file, but it seems that when the call to cusros:to(line, col) uses both line and col values larger than the file, the line is set to the last line whereas col is set to the first character in that line. I think that the col should be the last character of the line.

Edit: Sorry, the last line is the single addressable newline, so column 1 is correct.

[Marc André Tanner]

handling of invalid positions: negative or beyond EOF

Negative and fractional arguments should now generally be rejected. Beyond EOF should be handled individually and needs to be revisited.

I would like to avoid adding special purpose arguments (like . to denote the current cursor position) to the C/Lua API. I think you could add this kind of functionality purely in Lua by overriding the implementation in the corresponding meta table.

[Erlend]

bump: clamping cursor.pos to max bytes would be nice! ( from Lua )

[Erlend]

Here is a a link to vim's autocmd doc, it might be helpful in determining API events.
InsertEnter, InsertLeave and CursorMovedI seem useful, or maybe a more generic mode-changed-event.

[James Campos]

i'd like access to the last inserted text; currently i have to find the current line and slice it up. vim puts this into the dot . register.

edit: actually, this doesn't help me. i want the currently being inserted text.

edit: basically, i want normal mode commands (without entering normal mode) as an api. not sure how that would work. i need to rethink this.

[Erlend]

I can't see a way to access the registers now from LUA, maybe there should be an API like:

Vis:registers(char)       -- get the content of the register given a char
Vis:registers_iterator   -- iterate the registers