Open
Description
Problem
The design, and usage, of remote plugins can be simplified, as described in neovim/neovim#27949
tl;dr:
- remove the concept of "remote plugins"
- instead, any Go module that imports the go-client can call RegisterHandler to handle requests from Nvim
- "remote plugins" become plain old Lua plugins which call RPC methods on the Go module
Solution
- Apply the above proposal to go-client. go-client already supports
RegisterHandler
, so the remaining tasks are:- "Encapsulate the stdio related code in a helper function."
- Update docs
- (Nvim 0.12) Remove old rplugin-related code
Deprecate the old rplugin interface.
Reference
- Implementation in node-client: WIP: redesign "remote plugins", eliminate "host" concept node-client#344
- discussion/samples of current go-client interface: How to get notified of `AutoCmd` events from within a `go-client` test fixture which is *not* a plugin? neovim#27371
- related pynvim issue: simplify remote plugins pynvim#567
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
zchee commentedon May 12, 2024
@justinmk I don't understand all the new "remote modules" behavior yet, but I decided to work on the migration process ASAP.
ghost commentedon May 13, 2024
Delete the plugin package and any references to that package in the documentation.
The package accomplishes this goal as is:
Step 1 The application creates a new Nvim client connected to stdio:
Step 2 The application registers handlers with the nvim client using the client's RegisterHandler method.
Step 3 The application runs the the RPC message loop.
Optional enhancement Encapsulate the stdio related code in a helper function.
Example use:
Edit: I moved the call to v.Serve() from the helper function to the application's main. This gives the application more control over how Serve() is run.
Edit: I wrote the code in this comment directly in the issue tracker. The code has not been compiled, let alone tested.
justinmk commentedon May 13, 2024
@garyburd thanks so much, that is very helpful. So this is basically already supported by go-client.
💯
ghost commentedon May 13, 2024
@justinmk Yes, it's already supported. I propose the following:
Prepare for plugin deprecation.
Add new directory examples/remote containing the following:
The immediate goal is to post minimal working code using the package as is. Let's wait for progress on neovim/issues/27949 before adding the proposed helper function, writing complete documentation and adding tests.
I have some time for this in the next couple of days. @zchee and @justinmk let me know your thoughts on the proposal.
zchee commentedon May 14, 2024
@garyburd cc: @justinmk
Totally understand and almost agreed to your proposal. Thanks for quickly improvement!
More comment later, because now JST is start working time.
justinmk commentedon May 14, 2024
Sounds good!
27949 won't be a "big bang", we'll have to do it incrementally.
Since go-client already has
RegisterHandler
, if we provide a full example (#172) that shows a Lua plugin starting a go-client process and calling RPC methods viavim.rpcrequest
/vim.rpcnotify
, there isn't really anything blocking us from officially deprecating the go-client rplugin support.This will be doubly helpful, as an end-to-end demonstration of the logistics for 27949.
Of course, in the future Nvim may gain nice-to-have features that make it more convenient to spin up a long-lived client and call its RPC methods. But I don't see that as a requirement for this phase.
ghost commentedon May 14, 2024
@justinmk I wanted to wait on 27949 before adding an API in case the work on 27949 exposes additional requirements for the API. If you think things are baked enough, then I'll proceed ahead with the API and deprecation. I may not be able to get to it for a couple of weeks.
Here's a list of public Go plugins: https://pkg.go.dev/github.com/neovim/go-client/nvim/plugin?tab=importedby
justinmk commentedon May 14, 2024
We may weave-in more nice-to-have ideas later, but that will just upgrade the UX rather than be a hard requirement.
Currently, the (informal) requirements for a remote plugin are: