vim.lsp.rpc.connect doesn't works on windows about neovim

[pogyomo]

@mfussenegger I just try it with #28507 and found vim.lsp.rpc.connect works correctly so that vim.lsp.get_clients returns client infomation.

[TheLeoP]

This may be related to this regression. Maybe the problem isn't only with named pipes, but with windows being slower in general to connect to named pipes and TCP.

The problem is that Neovim sends the initialization request here

neovim/runtime/lua/vim/lsp.lua

Lines 426 to 441 in af8500a

	function lsp.start_client(config)
	local client = require('vim.lsp.client').create(config)
	if not client then
	return
	end
	--- @diagnostic disable-next-line: invisible
	table.insert(client._on_exit_cbs, on_client_exit)
	all_clients[client.id] = client
	client:initialize()
	return client.id
	end

which may happen before the TCP/named pipe connection has been stablished here

neovim/runtime/lua/vim/lsp/rpc.lua

Lines 683 to 687 in af8500a

	if port == nil then
	handle:connect(host_or_path, on_connect)
	else
	handle:connect(host_or_path, port, on_connect)
	end

[TheLeoP]

Using a command works because it handles the body since the command is launched

neovim/runtime/lua/vim/lsp/rpc.lua

Lines 746 to 748 in af8500a

	local stdout_handler = M.create_read_loop(handle_body, nil, function(err)
	client:on_error(M.client_errors.READ_ERROR, err)
	end)

neovim/runtime/lua/vim/lsp/rpc.lua

Lines 761 to 770 in af8500a

	local ok, sysobj_or_err = pcall(vim.system, cmd, {
	stdin = true,
	stdout = stdout_handler,
	stderr = stderr_handler,
	cwd = extra_spawn_params.cwd,
	env = extra_spawn_params.env,
	detach = detached,
	}, function(obj)
	dispatchers.on_exit(obj.code, obj.signal)
	end)

while connecting via TCP/named pipe starts handling the body once the connection has been established:

neovim/runtime/lua/vim/lsp/rpc.lua

Lines 679 to 681 in af8500a

	handle:read_start(M.create_read_loop(handle_body, transport.terminate, function(read_err)
	client:on_error(M.client_errors.READ_ERROR, read_err)
	end))

[TheLeoP]

Would there be a prefered aproach for a PR addressing this? I can think of:

• Using vim.schedule_wrap to ensure the initialization request is made after the TCP/named pipe connection has been stablished (it's a workaround and may cause more problems in the future)
• Refactor the code to send the initialization request inside a callback provided by client. vim.lsp.rpc.start would use this callback inmedeatly after calling vim.system if everithing is ok and vim.lsp.rpc.connect would do the same inside the on_connect callback, after initializing the read loop

[mfussenegger]

@pogyomo can you try with #28507 ?