It seems like the tests are failing because there is no ~/.ssh/config file. Should I update the code to not throw an error if it fails to read the config or create a temporary file for the purposes of the test?

Just added a check for whether the file is readable using vim.fn.filereadable() 😅

Here is a video showcasing the connect ssh:// feature. siddhant@localhost is directed to a Linux VM running on VirtualBox. Sorry for the flickering, couldn't figure out how to screengrab properly.

Linter is failing with:

/home/runner/work/neovim/neovim/runtime/lua/vim/net/_ssh.lua:294:17: value assigned to variable resp is unused

but resp is being used a few lines later here:

          ssh_prompts[i].value = resp
          processed_idx = #stdout
          vim.api.nvim_chan_send(job_id, resp .. '\n')

Not sure why it's failing

For a test, I have currently thought of this: calling `:connect ssh://localhost' should have one of three possible results (barring errors):

1. It prompts the user for a password
2. It asks the user whether they would like to verify the keyring
3. It connects to a server running on localhost

So, we call :connect ... and then test for each of the separate possibilities (simply quit the command if it asks for any prompts).
Not sure how we would check for the error situations though (ssh not being installed)

Thoughts @justinmk ?

I didn't like how the command to find a free socket on the remote machine was working before, felt a bit flaky (there were some false positive possibilities), so I've changed it. The current method will enforce a minimum version of Neovim on the remote machine, I'm not sure if this is a problem.

I've added a few basic test which does validation on the address passed to ssh.connect_to_host() (can't be nil, cant be empty, can't contain spaces)

Not sure how we would check for the error situations though (ssh not being installed)

Exercising the codepaths is the first priority. Exercising failure modes is also important, but can be a later step.