Alternative installation method

[luckasRanarison]

Edit: Writing the files when building the docs is done synchronously and freezes neovim for a moment. My initial thought was to create another program for managing docs but I prefer sticking with the current method, so instead I want to make write asynchronous.

[emmanueltouzery]

Do you intend to still allow to download from neovim (as currently) for users who'd prefer that?

[luckasRanarison]

Yes, but I think most of people would be confused if the editor freezes when building docs with neovim

[emmanueltouzery]

I'm not too sure, but I think it is or will soon be possible to have non blocking lua tasks:
neovim/neovim#17386

It's that's not enough (I really don't know), a hack for now could be to spawn another neovim (running your own code) to perform the computation, it's easy to work spawn other processes async. Or just name the call DownloadBlocking and warning the user before starting so it's less jarring. For me I'd go very far before I'd consider introducing another language/stdlib/runtime.

[emmanueltouzery]

More details on the threading:
https://www.reddit.com/r/neovim/comments/t2oc7w/neovim_now_supports_true_threads_via_libuv/

[emmanueltouzery]

I think coroutines also exist:
https://www.reddit.com/r/neovim/comments/ld83tj/help_me_understand_this_lua_plugin_with_coroutines/

I think also diffview may use them (but unsure).

[emmanueltouzery]

Ok last link I'm dropping and then I shut up:
https://github.com/ms-jpq/lua-async-await

[luckasRanarison]

Ok last link I'm dropping and then I shut up:
https://github.com/ms-jpq/lua-async-await

It's fine :), I really appreciate your help. I'll take a look at it. The only blocking operation is writing files, plenary provides a way to read files asynchronously but it doesn't provide a way to write files asynchronously.

[emmanueltouzery]

I'd not assume plenary wraps all possible calls.

I'm without a computer this week, but maybe vim.loop.libuv_fs_write() or something?

Or ask in some neovim forum or similar.

https://teukka.tech/vimloop.html

[luckasRanarison]

Using a separate thread in neovim still blocks the input, and it's kinda inevitable.

Like you, I also want to keep installation inside neovim. But freezing when downloading really annoyed me recently, it uses a lot of RAM and sometimes also entirely freezes my computer.

I've found this and it could be interesting https://github.com/neovim/node-client. I think most of people already have node installed and the only needed dependencies are the neovim client and the treesitter node binding, I'll just have to rewrite the transpiler in js. Leaving the heavy operations to node sounds better and it'd still be a part of the plugin.

[emmanueltouzery]

It's 100% your call, obviously! You know best 👍

And thanks again for the plugin!!

[luckasRanarison]

I was wrong during all this time, writing files is really fast. Freezing actually happens when transpiling, but treesitter APIs are not available yet in multi-threaded code so transpiling must be done synchronously. Maybe in the future that will be possible but I'll work on a remote plugin using node as an alternative for now.

[emmanueltouzery]

I know that some plugins are launching a separate neovim in another process to do things like that. That could achieve the desired effect without requiring much new work, or having to install node and so on?

[emmanueltouzery]

I remembered which plugin spaws a separate neovim instance for async processing:
smjonas/live-command.nvim#29

I'm not saying it's necessarily a good idea.. in fact it should probably be avoided at all costs if at all possible. But in some extreme cases it's possibly the least bad option. Maybe keep in mind that it's an option.

[luckasRanarison]

I remembered which plugin spaws a separate neovim instance for async processing: smjonas/live-command.nvim#29

That's a really interesting idea! Neovim rpc interface is really powerful, I'll try some stuff and see how it goes.