Sometimes treesitter calls for an invalid column within a line, checking
that the column is actually valid and forcing the value avoids an
integer overflow and an infinite sequence of invalid reads.
Fixes#12131
- We already find ourselves renaming nvim_execute_lua in tests and
scripts, which suggests "exec" is the verb we actually want.
- Add "exec" verb to `:help dev-api`.
- Add vim variable meta accessors: vim.env, vim.{g,v,w,bo,wo}
- Redo gen_char_blob to generate multiple blobs instead of just one
so that multiple Lua modules can be inlined.
- Reorder vim.lua inclusion so that it can use previously defined C
functions and utility functions like vim.shared and vim.inspect things.
- Inline shared.lua into nvim, but also keep it available in runtime.
Mainly configuration and RPC infrastructure can be considered "done". Specific requests and their callbacks will be improved later (and also served by plugins). There are also some TODO:s for the client itself, like incremental updates.
Co-authored by at-tjdevries and at-h-michael, with many review/suggestion contributions.
compared to vim.api.|nvim_call_function|, this fixes some typing issues
due to the indirect conversion via the API. float values are preserved
as such (fixes#9389) as well as empty dicts/arrays.
Ref https://github.com/norcalli/nvim.lua for the call syntax
Forcing insert-mode after the first paste-chunk seems to work, as an
alternative to a9e2bae0eb (insert-before-cursor).
NB: Dot-repeat needs to match the original action. Since a9e2bae0eb
changed paste to insert-before-cursor, dot-repeat must also. But that
makes dot-repeat unpleasant/unusual.
Inserting "after" the cursor in Normal-mode, for big paste-streams, is
not reliable: sometimes the text "after" the cursor ends up in the
middle of the pasted text. Maybe the cursor position is not updated?
To avoid weird behavior, always paste "before". Maybe nvim_put() or
vim.paste() can be fixed more properly later.
