When we do <LocalLeader>rf over the word function, nvimcom sends a string that is invalid for Lua: it contains a backslash before a parenthesis. The simple workaround would be to escape the backslash before sending the help text to R.nvim. However, the more appropriate fix is to escape all strings sent to R.nvim in a standard way. There is a function for this (nvim.fix.string() at R.nvim/nvimcom/R/bol.R), but it was developed to escape strings for VimScript, not for Lua, and, before trying to further adjust it to Lua, I would like to know what are @she3o ideas on the C-Lua interface:
Is the plan to convert the whole C code to Lua or to turn rnvimserver into a C library for our Lua code?
What would be the advantages over the current approach of running rnvimserver as a Neovim job?
Currently, if rnvimserver crashes, R.nvim stops working, but Neovim doesn't crash. As far as I know, if rnvimserver were a C library, a fatal error in its code would crash Neovim. This would be a disadvantage of rnvimserver as a C library. Another disadvantage would be the dependency on Lua headers for compilation, but this is easily solved by including the Lua headers in the R.nvim directory.
If we converted the whole C code to Lua, this would result in a loss of performance because in C we have total control of memory management and direct access to string arrays.
In summary:
C application: better at processing data, but slower transferring information to R.nvim.
Lua only: slower at processing data, but no need to transfer data.
C library: better at processing data and fast transferring data.
From the above comparison, considering that there are no reports of the nvimrserver crashing, the most advantageous approach for R.nvim seems to be the conversion of rnvimserver into a C library for our Lua code. However, considering that the current approach of running rnvimserver as a job is already pretty fast, it might be better to leave it as is and simply fix the nvim.fix.string() function.
When we do
<LocalLeader>rfover the wordfunction, nvimcom sends a string that is invalid for Lua: it contains a backslash before a parenthesis. The simple workaround would be to escape the backslash before sending the help text to R.nvim. However, the more appropriate fix is to escape all strings sent toR.nvimin a standard way. There is a function for this (nvim.fix.string()atR.nvim/nvimcom/R/bol.R), but it was developed to escape strings for VimScript, not for Lua, and, before trying to further adjust it to Lua, I would like to know what are @she3o ideas on the C-Lua interface:Is the plan to convert the whole C code to Lua or to turn
rnvimserverinto a C library for our Lua code?What would be the advantages over the current approach of running
rnvimserveras a Neovim job?Currently, if
rnvimservercrashes,R.nvimstops working, but Neovim doesn't crash. As far as I know, ifrnvimserverwere a C library, a fatal error in its code would crash Neovim. This would be a disadvantage ofrnvimserveras a C library. Another disadvantage would be the dependency on Lua headers for compilation, but this is easily solved by including the Lua headers in theR.nvimdirectory.If we converted the whole C code to Lua, this would result in a loss of performance because in C we have total control of memory management and direct access to string arrays.
In summary:
C application: better at processing data, but slower transferring information to
R.nvim.Lua only: slower at processing data, but no need to transfer data.
C library: better at processing data and fast transferring data.
From the above comparison, considering that there are no reports of the
nvimrservercrashing, the most advantageous approach forR.nvimseems to be the conversion ofrnvimserverinto a C library for our Lua code. However, considering that the current approach of runningrnvimserveras a job is already pretty fast, it might be better to leave it as is and simply fix thenvim.fix.string()function.