You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 19, 2022. It is now read-only.
luarocks => [wbthomason/packer.nvim] has now support luarocks packages => add firejail profile for luarocks done, but I want to test it further before upstreaming. Currently I have weird folder quirks.
:checkhealth integration => check core and treesitter implementation
"Note that underscore-prefixed functions (e.g. "_os_proc_children") are internal/private and must not be used by plugins" => dont use underscopre-prefixed functions
Guidelines how to name functions. local function a = bla() vs local a = function(). Related function M.bla() for a table.
I copied some content to the plugin template project and will delete this issue, once the stuff is documented there properly.
The text was updated successfully, but these errors were encountered:
I've been reading the guide and I'm trying to understand the difference in performance between vim.api and vim.fn. In the reddit thread, now closed for comments, it mentions that vim.api is faster than using vim.fn because the api goes direct to C while fn goes to vimscript then to C.
However, while reading the neovim help, it mentions that vim.api is implemented using named sockets on the local system and message pack, which seems to imply that all calls have to round trip via kernel and socket. I'm trying to understand if the vim.fn bridge uses vim.api under the covers or if it is "native" and can invoke functions directly without the overhead of the socket and message pack.
If it is the latter, would performance be best described as:
vim.api -> socket/message pack -> C vim.fn -> vimscript -> C
And then the question becomes is there more overhead with with socket/kernel roundtrip or vimscript intermediary steps?
To summarize with an example, I guess I'm just wondering if every vim.api call must be go through the named socket and be serialized. If so, would vim.api.nvim_get_lines be less "efficient" than using vim.fn.getbufline?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The one and only luajit wiki and luajit not yet implemented.
Performance tips: wiki
+ wait for status information, computing performance guide recommended by scilua authorDebugging: one step for vimkind
luarocks => [wbthomason/packer.nvim] has now support luarocks packages => add firejail profile for luarocks done, but I want to test it further before upstreaming. Currently I have weird folder quirks.
:checkhealth integration => check core and treesitter implementation
Explaining what is most performant and why (vim.api) and what happens under the hood ie for
vim.call
,vim.fn
etc. (blocked by missing documentation upstream) see Mention vim.api.nvim_call_function #6https://www.reddit.com/r/neovim/comments/oeevcy/what_is_the_difference_between_vimapi_and_vimfn/h45ujiz?utm_source=share&utm_medium=web2x&context=3
"What is the difference between
vim.api
andvim.fn
functions?""you can no longer use api functions from vim.fn which used to be the case
vim.api is nvim specific functions and it goes from lua -> C while vim.fn is viml functions which goes from lua -> viml -> C
there's more overhead for using vim.fn than vim.api"
Some internal functions (categories?) and how to find more etc
Plugin guidelines:
plugin
folder makes profiling annoying/kinda breaks it): A Lua-aware startup time profiler nvim-lua/wishlist#15 (comment)=> dont use underscopre-prefixed functions
local function a = bla()
vslocal a = function()
. Relatedfunction M.bla()
for a table.I copied some content to the plugin template project and will delete this issue, once the stuff is documented there properly.
The text was updated successfully, but these errors were encountered: