Could you explain some lines of your code?

[nyngwang]

Hi, I'm learning about Neovim's rpc features and I found your plugin a good resource to learn them. Could you explain the following code in your implementation? In particular:

• What are the possible values of block?
• Why we don't need to call chanclose when it's value is not nil?
• Why do we need to put an infinite loop after chanclose?

Thank you in advance!

flatten.nvim/lua/flatten/guest.lua

Lines 17 to 24 in 17bbf3e

	local block = vim.fn.rpcrequest(host, "nvim_exec_lua", call, {})
	if not block then
	vim.cmd("qa!")
	end
	vim.fn.chanclose(host)
	while true do
	vim.cmd("sleep 1")
	end

[willothy]

Totally! Block is a boolean that tells the guest instance whether to wait for the host to close the file before exiting. It is sent from host to guest as the return value of Core.edit_files(). If block is false, the guest exits immediately leaving the files open in the host Neovim instance. If it's true, the guest sleeps indefinitely until the host tells it to quit (call to rpcnotify() on core.lua:5), so that external programs such as Git can wait for a file to be written and closed, as is necessary for commits.

The chanclose() function is used to close the connection from the guest to the host. It's not strictly necessary in this case as the guest instance will exit and terminate the server when blocking is complete anyways, but the guest doesn't need to send messages to the host after that point so that's where I close the socket.

not block on line 18 checks if block is false, not if it's nil. I just happened to use not instead of == false as it's more concise and will still result in the expected behavior if block were to be nil for some reason.

If you want to learn more about RPC I'd highly recommend reading the official API docs, I found those to be the most helpful resource when implementing this in addition to others' RPC-based plugins.

Thanks for using my plugin, let me know if there's anything else you're curious about :)

[willothy]

Glad I could help! Yeah, the result of rpcrequest is the reply it receives. In the case of a call to nvim_exec_lua or similar that would be the return value of the Lua expression that is executed, if there is a result. Of course, I'm not bothered by the follow, I appreciate the interest in my work :)

[nyngwang]

While the three questions in my OP all have been answered by you, I still have one question regarding your reply:

(part of the second paragraph)

The chanclose() function is used to close the connection from the guest to the host. It's not strictly necessary in this case as the guest instance will exit and terminate the server when blocking is complete anyways, [...]

Why the guest instance would terminate the server when blocking is complete? (if I read it correctly) By intuition, I will expect that it's the reverse, i.e. the server will terminate the guest instance.

I also have a question when using flatten.nvim that is possibly related to this question: In the original nvim (server) instance I have vim.fn.argc() that prints 0(as I started Neovim with nvim without any arguments), but after running git commit in the terminal buffer and go back to the server instance, it prints 1(I guess git commit will internally call nvim path/to/git/related/file). Is this related to the fact of "the guest instance will exit and terminate the server" here?

[willothy]

I think my terminology might be a bit misleading, that's my bad. When I say guest, I'm referencing the "nested" neovim instance that you would be opening from the terminal. When I say host, I mean the parent instance, the one the files will actually be opened in. The server that's being terminated with chanclose isn't the Neovim instance itself, but the RPC socket created by the guest to send commands to the host.

Essentially, the guest will close itself as soon as it doesn't need any more work (aka if it's non-blocking), but if it needs to wait it closes the connection as it's no longer necessary for the guest to send commands to the host after the initial request. You are correct that the host terminates the guest, I just explained it in a bit of a confusing way. I wanted to use guest and host to make it simpler to differentiate the Neovim instances from the RPC servers, but maybe that just makes it more complicated haha

The plugin uses argadd to open new files, which is why argc shows more than the original number after opening a new file. I don't think this should cause any issues (it's just the argument, not the file itself still being open), but if it does I'll look into refactoring that.

[nyngwang]

Again, I appreciate your detailed response. (words cannot convey all my thankfulness)

I think my terminology might be a bit misleading, that's my bad. [...], but the RPC socket created by the guest to send commands to the host.

No, it's my fault that I failed to recognize your careful wording there (I read host as server subconsciously, lol). And yes, I need to study more about socket and rpc :P (I failed to learn them in the past, unfortunately)

The plugin uses argadd to open new files, which is why argc shows more than the original number after opening a new file. I don't think this should cause any issues (it's just the argument, not the file itself still being open), but if it does I'll look into refactoring that.

Believe it or not, this used to be an issue for me: My plugin was dependent on vim.fn.argc() and I didn't know that $NVIM will be set in guest instance, but I have fixed it. I still think it's a good idea to restore all the states after leaving a nested instance, please(?)

Anyway, I don't have any further issues in this thread. Thank you!!

[willothy]

Yes, will definitely look into removing blocking files from args after they're closed once I've finished the piping into buffers feature. Again, thanks for using my plugin, and for your PR! Glad my answers were helpful.