Is there any plan to support NeoVim?

[StrayDragon]

Thank you for developing this plugin 👏 , It satisfied my need totally. However I encountered a series of problems when I tried to make vim-padre compatible with NeoVim:

• the job feature attribution (so I commented some related code to skip check, it worked)
• ++curwin cmd (I just removed it from source code, it worked)
• not has ch_* API functions (this is a fatal problems and need replace some similar API, it dead...)

I checked many relevant document, but I'm not very familiar with ch_* sockets API, can give me some suggestions and help?

Thanks again!

[strottos]

Thanks for raising the issue. Neovim is currently not something I either use or have investigated as part of this work but I'd be happy if it could. My only aim initially was Vim, but in theory it shouldn't be hard to port to Neovim because I've tried to put all the heavy lifting in the Rust binary. Admittedly I don't know the differences but I'd be more than happy for someone to try and make them compatible. If it can be changed to support Neovim I'm more than happy to merge it in but it's unlikely I'll have time to look at this myself at present. Sorry about that.

As I say in theory it's not too hard, it just needs to make sure that Neovim will spawn the padre debugger and we're good. Happy for us to just put some if/else statements in to support both say.

[StrayDragon]

Yes, As you said, the key to solving the problem is that Neovim can schedule the padre and communicate with it, and understand the differences and migration methods of NeoVim and Vim in processing related interfaces. After learning those, I will try to solve it.

In addition, I tried to read some code of padre. Unfortunately, I am just a Rust beginner. Some related libraries and usage are not very familiar. I will try to learn them and have to say that this is a very good learning material.

I am looking forward to have a good debugging and profiling experience by using padre in Vim / Neovim, that will be too powerful. And I even feel that it is possible to replace some IDEs functions in some extent for me.

Anyway, thanks for your reply and have a nice day :smile:

[strottos]

Pleasure, thanks for looking into it. I basically learned Rust by writing this, I'm no Rust expert but learned an awful lot by doing this. Possibly Go would have been a better usage in some ways but performance was super important and I suspect Rust will outperform what Go would have done. Either way I'm happy to help where I can with Rust stuff. I'll also shamelessly point out a couple of Rust articles that I wrote if you fancy looking into it, won't teach everything you need for this yet but they'll get you somewhere: https://dev.to/strottos/learn-rust-the-hard-bits-3d26

Either way thanks for checking it out, anything you can contribute is greatly appreciated.

[strottos]

Also a warning that I'm currently trying to refactor the padre command heavily by upgrading Tokio 0.1 to 0.2. There's been a heavy focus on Rust to get Async stuff into the language and I use it everywhere to save having to multi-thread to do things like read and write to stdin of processes and I'm trying to play catchup. In the process I've done a bit of a refactor, shouldn't matter much to the interface and I have tests to check that kind of thing so anything just in Vim code won't matter, but worth being aware of. This could take anywhere up to 3 months I suspect as not only is it my time but it's also waiting for other Rust Crates to catch up too, like something to do WebSockets for the Node debugger.

The only real changes to the interface are:

• Everything returns immediately and queues and then everything with info in it should be done with callbacks.
• Lots of callback stuff in VIM retired. Checkout the feature/tokio-0.2 branch if curious there. It's nowhere near ready yet though. The Python debugger is the most complete, LLDB is a bit of a pain right now as is Node for various reasons.

[StrayDragon]

Sorry for the late reply, I just finished reading the first post you mentioned above, brilliant learning materials. The simple example of the concept of borrow check gave me some different understanding ideas, I have some experience with C ++ and Python, the borrow and move semantics in Rust are similar to std::unique_ptr and std::move in C ++ (Is this correct ?). However, I consider that I still need to understand some Rust concepts in further practice like you, This is an effective way to learn Rust. The second post is also already in my reading queue, and I will continue to pay attention. It is very pleasant to talk with you about these.

In addition, thank you for reminding me that I need to pay attention to the interface changes brought by the upgrade of tokio and related crates, but I am currently busy with college exams, and once those things are over, I will do my best to try to understand some code and make some changes. Giving more patience for padre is well worth it, so I'm not worried that this may take a lot of time, and I still look forward to the next version.

Thank you for making it open source, which has benefited me a lot. :heart:

[strottos]

No worries at all. Whenever you have time it is appreciated. If that turns out to be never I completely understand that too. Good luck with your exams.

[strottos]

Oh and yes you're basically right, Rust doesn't really do that much above what C++11 gives you as I understand but it gives you it both by default and by forcing you to abide by these rules rather than hoping developers will use these techniques. Rust has been an absolute pleasure for me to learn personally and I wish you luck with it. It really is a thing of beauty in my eyes.