Join forces?

[noib3]

Hi there!

While developing nvim-compleet I put together the nvim-bindings crate to provide Rust bindings to Neovim without having to deal with RPC. Now I was asked to extract that crate to its own repo for other plugin authors to use. Would you be interested in merging overkill_nvim into that crate?

Native FFI bindings is something nvim-bindings is currently lacking and we could reuse a lot of your code there w/o having to implement it again.

Thanks.

[turboladen]

Hi @noib3! I keep meeting to check out nvim-compleet--when I saw that project pop up (on reddit?), I got really excited at the promise. Truth be told, my motivation for this repository was to work towards some sort of completion engine, but one that didn't have to rely on lua (nothing against lua, I just prefer Rust 😄 ). Additionally, all of this work wasn't necessarily something that I really wanted to do (although it's been interesting digging into neovim's source!), rather just a tool that I wished someone else had made so I could use it.

All that to say: yup, I'm all for merging things! How do you see that happening? Any thoughts? I poked through your source and did notice an opinionated directory; I didn't check to see what the opinions were about, but it did make me think about my stuff here a tad... My thoughts in having 3 crates were:

1. neovim-sys = just the C bindings
2. nvim_api = started off trying to mimick the lua API, but ended up diverging here and there. I didn't want to add many special types or too much functionality that doesn't stay close to what the lua API affords you; I figured some people might not need/want more than this.
3. overkill_nvim = opinionated "framework" (?) on making things. In general, the idea was that I'd be able to represent neovim concepts via types, preventing me from doing dumb things. In fact, in converting my init.vim (which had morphed over the past 20 years) to Rust, I realized that a number of things I was specifying weren't even possible, but (neo)vim never told me. Not a huge deal of course, but I definitely prefer to know when I think I'm doing something, but it's not working. I digress...

For my part, I think this organization makes sense, but that's not to say that there isn't a better way. ...or it might not even be such that anyone else cares about having things broken up like this. But I'm open to going away from this if it means more adoption (again, I really just want a non-RPC tool/lib that I can use to do my own nvim things). Do you have any thoughts on this?

Lastly, I should add that there are still a lot of rough edges in this codebase. ...and in fact, I'm not even certain I'm using the best calls in neovim--I really just tried started off by looking to see what the lua API does internally, then going from there. Testing is also kinda funky/not ideal/a bit of a drag.

Anyway, lemme know your thoughts and thanks for the ping!

[noib3]

Do you have any thoughts on this?

I think this approach makes sense. I was thinking of dividing the library in two layers:

• one which should aim to be a 1:1 port of Neovim Lua api. Everything from vim.api, vim.fn, vim.lsp, vim.treesitter, etc.. should go in there. We could also just put the C bindings in here as well;

• another one which provides a higher level interface to the official api, or anything else that diverges from it. This is kinda like your overkill_nvim or my opinionated module.

I poked through your source and did notice an opinionated directory; I didn't check to see what the opinions were about

Pretty much anything that wasn't a boring Rust rewrite of a Lua function went in there. It's not complete by any means, I've just been adding function as I need them for now.

The completion results in nvim-compleet are computed in a separate tokio thread pool to never block the UI thread. However, some sources may need to fetch informations from Neovim to compute their completions, so I needed a way to let the tokio workers make requests to the main thread. That's what the neovim, signal, lua_bridge and bridge_request modules are for. I'm not sure that's the only/best approach but that's what I'm doing right now.

Lastly, I should add that there are still a lot of rough edges in this codebase

Yup, same for my nvim-bindings.

Do you have any ideas for the name? nvim-rs is already taken. I was thinking of nvim-oxi as in "oxidized" (bc of Rust... get it? Yeah I'm bad at names), but I'm open to suggestions.

[turboladen]

All sounds good to me! It probably took me 2 weeks to come up with "overkill", so yeah, naming sucks. 😀 I don't think I feel that strongly about what we'd end up with.

So with that, did you have thoughts about how to move forward? Like, after we land on a repo name, what would see as first steps? Moving your stuff first? Moving mine first? Moving and merging things "feature by feature" (ex. Option getting/setting = feature)?

[noib3]

what would see as first steps?

I think we should port the bindings to the C types first, which if I'm not wrong should be contained in your neovim-sys crate. I just set up a basic workspace structure with two crates, oxi-types for the type definitions and oxi-core which I think could contain the 1:1 port of the api. Of course, feel free to change the names/move things around, you should have write access to the repo.

Moving and merging things "feature by feature" (ex. Option getting/setting = feature)?

I was thinking of going "table by table", starting with implementing vim.api, which is the core of the Neovim api. Then vim.fn after that. "Runtime" stuff like vim.lsp and vim.treesitter will probably be the last.