Roadmap

[KillTheMule]

Short-Term

• Update to latest neovim release
• Check if we can/should support other runtimes (I've some glib code lying around I could brush up... maybe others have arisen now?)
  • Remove async_std in favor of smol #55
• Expose stderr #54

Mid-Term

• Consider making a difference between requests and notifications, and send out notifications with the proper message type, and don't wait for a response
  • Does neovim actually recognize this? Read the docs! Maybe everything's a requests anyways, then don't bother
    • It does, see https://neovim.io/doc/user/api.html#api-global-events. Maybe not so usefull since there seems little to do where you don't want direct error feedback
  • Requests vs. Notifications #7

Fuzzy goals

• Need more tests
  • Test all connection types on all OSes
  • Test exttypes
  • Check https://docs.rs/loom/0.2.14/loom/
• Check rust's API guidelines
  • Rust API Guidelines Checklist #9
• More examples

Things to think about

• Could we reasonably offer a single-threaded API, i.e. doing away with Send and Sync? Don't want to duplicate it all, but since we're generating the neovim API automatically anyways, it might be feasible
• Consider logging
  • Maybe tokio's tracing is an idea?
• Rewrite the API to be type save, and hide rmpv::Value from the user
  • Maybe hiding rmpv::Value isn't helpfull or needed?
  • Can probably be done for outgoing requests by recursively creating values
    • Fixed args are easy, but something like nvim_call_function probably needs going through a trait
  • Incoming Responses can be done like fixed args
  • Incoming Notifications/Requests might be impossible.
    • Check out rmp-serde or so, so maybe the user has to just declare a struct
  • Strongly typed API #8

Old stuff

• Figure out how plugins can quit
  • Quitting a plugin #2
• Can we merge Requester into Neovim? Could avoid doubling the API
• Figure out what to do if the handler needs some cleanup logic
  • Add handle.close #3
• Consider error handling
  • Maybe get away from Box<dyn Error> in favor of a small enum?
  • Error handling #6
• Document the library
  • I consider this done initially, from now on everything new should be directly documented, and we should be fine.
• We need Tokio right now. What can we do to stay "as generic as possible", so we can move to other executors when the possibility arrives?
  • Use stuff from futures as far as possible.
  • See what we really need to expose from crate::runtime

[unrealhoang]

First, thank you for your effort of creating this project. I've also been discovering neovim rpc in Rust and neovim-lib was not satisfying enough.

For

Rewrite the API to be type save, and hide rmpv::Value from the user

You can rely on rmpv::Value with serde feature and deserialize Value (or ValueRef) into user-defined struct. Your lib could also pre-define popular structs as well. Here is an example of me using in my project:
https://github.com/unrealhoang/lspc/blob/master/src/neovim.rs#L301-L312

[KillTheMule]

Ahh very cool, I was hoping for something like this. Seems like it's an achievable goal to hide Value from the user :) Thanks!

[thjbdvlt]

@KillTheMule As I'm developping a Neovim GUI using nvim-rs, I'd like to contribute to the project (I've already submit a very-minimal-now-merged one-line-PR). Is this roadmap still the place to look for things to be done?

[KillTheMule]

Hey thanks for your interest! I've not been able to put enough time into this, unfortunately, so you're very right to ask :)

The list probably hasn't aged very well, I need to go through it and investigate things a bit. I've in particular soured about the strongly-typed API (if we can't do it consistently, we should probably just forego it; consistency is a value of its own in a library). But some others are even unclear to me now 😁

If you want to get going, there are several things that are needed anyways:

• Update to latest neovim release
• Check if we can/should support other runtimes (I've some glib code lying around I could brush up, and Remove async_std in favor of smol #55 is still relevant ... maybe others have arisen now?)
• Expose stderr #54 is still relevant
• On a higher level: Could we reasonably offer a single-threaded API, i.e. doing away with Send and Sync?

I'll go through the "larger" roadmap and update it soon, I'll let you know via this issue :)

[KillTheMule]

Ok, I've updated the roadmap, if you've further questions let me know.

[thjbdvlt]

@KillTheMule Thank's for your answers and the update! I'll check what I can do :)