search

daa84 / neovim-lib

Rust library for Neovim clients
GNU Lesser General Public License v3.0
191 stars 26 forks source link

Async/Await #37

Open KillTheMule opened 4 years ago

KillTheMule commented 4 years ago

Now that it's available on stable, it seems like a premier way of solving https://github.com/daa84/neovim-lib/pull/23. Do you have any plans regarding that? I've thought a bit about it, and it seems like that would result in a major breaking change, but it's the first time I'm dabbling in that stuff, so I might just not have had the right idea.

KillTheMule commented 4 years ago

For anyone interested, I started investigating this at https://github.com/KillTheMule/neovim-lib/tree/async. Any help welcome, I've never worked with async up to now. Right now, even the tests are passing, but I do not have any idea if that does what I think it does :)

KillTheMule commented 4 years ago

I've put up a test that shows the basic use case I wanted to solve: The client takes a request, but before answering it, it needs to make some requests itself (see these lines, where we're handling the request req by requesting servername/progname, and finally responding with a concatenation). This is not possible without either this or any of the solutions in #23. Note that if you run this, you'll want to change the nvim path.

I'm not sure if that solve everything, though. One thing that will lock it up is using nvim.command to execute "rpcrequest(1, 'req', 'x'), because while awaiting nvim_command we're not dealing with new requests. That's somewhat convoluted though, but makes me wary what else might be missing. The fundamental problem here is that we can' task::spawn(nvim.command(...)), because nvim isn't Sync. I'll need to think if that's a feasible thing to achieve. You'd still be able to lock yourself up if you don't use the right combination of task::spawn, task::block_on, .await, but that is probably true for every such system.

Again, any comments welcome :) @daa84 If you're not interested and I should stop polluting your issues with that, let me know.

KillTheMule commented 4 years ago

So, I'm now at a point where I've got the basic functionality working, and I'll probably want to take this further, seeing the API is totally different anyways. Meaning, I'll be creating a fork of this lib. I've not heard from @daa84 by now, but if you ever come back to this and think we should collborate more, hit me up :) Other than that, thank you for your pioneering work!