[RFC] Inject distant support into neovim lua functions about distant.nvim HOT 3 CLOSED

nvimlsp-config support

For this plugin, I'm taking a quick look at all references to io, vim.cmd, vim.fn, vim.loop, and vim.lsp to see what it uses.

io

• open - ignore (ONLY USED IN scripts/docgen.lua)
• lines - inject
  • used in util.lua and vala_ls.lua where the util uses it in insert_package_json used by stylelint_lsp.lua and eslint.lua

vim.fn

• executable - inject
• expand - ignore (I think it's safe to ignore this one? Unless my concern about buffer/file names is valid)
• exepath - inject
  • used by config.lua (not a server) on a server config's command to resolve the full path of the executable
• filereadable - inject
• getcwd - inject
• getenv - inject
• getpid - inject
  • Should this be the pid of the distant server? It is used used in omnisharp.lua with --hostPID
• glob - inject
• has - inject
  • Caveat here is that we only need it for the situation where vim.fn.has('win32') is used since that implies Windows on the remote machine
• isdirectory - ignore (ONLY USED IN test/minimal_init.lua)
• jobstart - inject
• readdir - inject
• stdpath - inject (detect remote OS and use appropriate vim stdpath?)
  • Seems to be used for specifying logging path for an option with the vdmj.lua config
  • Used for part of the command for powershell_es.lua
• system - ignore (ONLY USED IN test/minimal_init.lua)

vim.loop

• cwd - inject
• fs_mkdtemp - ignore (ONLY USED IN scripts/docgen.lua)
• fs_realpath - inject
• fs_stat - inject
• new_timer - ignore
• os_homedir - inject
• os_uname - inject

vim.lsp

• start_client - inject

There's a bunch of others for vim.lsp, but we only care about start_client since that's what we need to wrap. Everything else does not touch the filesystem, spawn processes, etc to my knowledge. There are also a lot of calls to vim.api to get buffer names. My only concern there is if the plugin won't trigger start_client because of the distant://{ID}@ prefix on buffers. If that's the case, we'd need to overwrite buffer name retrieval as well.

For vim.cmd, I'm trying to see if any vimscript commands that do IO/processes are being invoked. If so, we'd have to replace cmd, parse the string, and detect that. If that's the case, this would be a deal-breaker. From skimming the source code, I don't see anything like that, it's just used to set autocommands or invoke :edit for zk.lua when running :ZkNew.

from distant.nvim.

nvim-dap support

For this plugin, I'm taking a quick look at all references to io, vim.cmd, vim.fn, and vim.loop to see what it uses. It does make one call to vim.lsp.util, which isn't important.

io

• lines - ignore (used to read a local .vscode/launch.json to extend with entries)
• open - ignore (used for logging of DAP, which we want locally)
• stderr - ignore (used to set neovim stderr for tests)
• stdout - ignore (used to set neovim stdout for tests)

vim.fn

• getcwd - ignore (used to look up .vscode/launch.json relative to local machine cwd)
• delete - ignore (ONLY USED IN tests/debugpy_spec.lua)
• getpid - ignore (returns neovim pid used to filter it out from a list of processes)
• has - inject
  • Caveat here is that we only need it for the situation where vim.fn.has('linux') and vim.fn.has('linux') are used since that implies Linux on the remote machine
• input - ignore
• jobstart - inject
• mkdir - ignore (used for logging of DAP, which we want locally)
• stdpath - ignore (used for logging of DAP, which we want locally)
• system - inject (used to retrieve process information to know which process to debug)
• trim - ignore

vim.loop

• fs_stat - ignore (used to examine local .vscode/launch.json)
• getaddrinfo - inject
  • used to resolve a host; if it fails, they return the unresolved host
• new_tcp - inject
  • used to connect to spawned processes (servers?) that I'm assuming expose a TCP port for debug purposes
• new_timer - ignore
  -os_uname - ignore (used to figure out path separator for logging)
• spawn - inject
  • used to spawn an external terminal
  • used to spawn a server executable
  • used to spawn a session from an adapter
• version - ignore
• walk - ignore (ONLY USED IN tests/run_server.lua)

For vim.cmd, I'm trying to see if any vimscript commands that do IO/processes are being invoked. If so, we'd have to replace cmd, parse the string, and detect that. If that's the case, this would be a deal-breaker. From skimming the source code, I don't see anything like that, it's just used to set autocommands, invoke commands like :DapProgressUpdate, edit a preview window (:pedit), or perform window manipulation.

In terms of gotchas, the new_tcp is the toughest one if we ignore the mix of needing and not needing IO based on reading a local VSCode configuration or writing log files. This is where distant would need to support TCP forwarding similar to SSH where we could run it and it forwards tcp traffic between the local machine and remote machine.

from distant.nvim.

From the two examples above, this is clearly quite complex and I don't think the automatic injection will be feasible unless we do something like one of these options:

1. Exclude based on the origin of the call to the function (e.g. you can say to ignore originating from log.lua), and let the origin be configurable. You would detect the origin using debug.getinfo() and see if where we come from:

   function traceback ()
     local level = 1
     while true do
       local info = debug.getinfo(level, "Sl")
       if not info then break end
       if info.what == "C" then   -- is a C function?
         print(level, "C function")
       else   -- a Lua function
         print(string.format("[%s]:%d",
                             info.short_src, info.currentline))
       end
       level = level + 1
     end
   end
   

2. Support turning on & off injection explicitly, still struggling when one plugin needs it remote and another needs it local
3. (most likely) Inject with a function where the injection happens, the function is invoked, and then the injection is undone. This would let you wrap calls to other plugin methods in a way that still supports distant. It just means that you have to do the injection more explicitly versus the seamless method.

from distant.nvim.