lua: add vim.fn.{func} for direct access to vimL function #11302
Conversation
|
nice! +1 for
Seems reasonable. We could also make |
That a bit too magical maybe, unless it serves some specific important usecase. If we want a function I would just leave |
bfredl
force-pushed
the
luacall
branch
2 times, most recently
from
058df7f to
1e9b374
Compare
bfredl
changed the title
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 neovim#9389) as well as empty dicts/arrays. Ref https://github.com/norcalli/nvim.lua for the call syntax
|
I kept |
|
|
||
| Note: unlike vim.api.|nvim_call_function| this converts values directly | ||
| between vimL values and lua values. If the vimL function returns a | ||
| float, it will be representeted directly as a lua number. Both empty |
There was a problem hiding this comment.
Typo here with representeted
There was a problem hiding this comment.
will fix it in next PR (if doc PR doesn't do it first :)
3 participants
Add a direct implementation of calling a vimL function from lua.
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 (ideally these should be distinguishable by a metatable, which is the canonical way of creating table "subtypes" and far less intrusive than
{[true] = 7, [false] = 3}thing). I might revisit this and other typing issues (such as a dedicatedvim.NILvalue asnildoesn't always work) in a followingvim.rpcrequestPR (which is my next lua addition, for a full "rpc client lib" in lua code).Also add convenient lua interface as
vim.funcs.fname(...). The namefuncsis fully bikeshedable. @norcalli has also suggested a similar interface as part of his "stdlib" work but insteadnvim.fn.xx, though it would bevim.fnhere if we use it. In fact perhaps this should be the only public interface, andvim.callinstead bevim._callimplementation detail.