search

kevinhwang91 / rnvimr

Make Ranger running in a floating window to communicate with Neovim via RPC
BSD 3-Clause "New" or "Revised" License
800 stars 17 forks source link

Single global daemon for all vim instances #115

Closed amerlyq closed 2 years ago

amerlyq commented 2 years ago

Idea

Keep ranger always running in background, outside of vim (like tmux). Connect all opened vim processes to single global running instance of ranger.

Benefit

Startup time -- no ranger spawning at all (especially if I spawn ranger from bashrc/systemd on startup). Single running ranger irrespective of how much vim instances I opened, or how frequently I open them. Keep single shared state between all of them -- i.e. working directory, etc. Individual projects workdirs can be kept by user in different tabs of ranger.

Solution

As I already have constantly running tmux server on my PC, it would be natural to simply lauch rnvimr in hidden tmux window and attach to it from inside neovim terminal which runs tmux attach. Chip and cool. It has an additional benefit, that I can attach to it from some other terminal too, not only from vim.

Problem

rnvimr can't be launched outside of vim session, as it queries vim variables.

How much do you think reworking needed to be able to launch rnvimr separately and connect to it?

kevinhwang91 commented 2 years ago
  1. tmux popup UI needs to adapt the nvim floating window. We can do this since tmux 3.2, but a lot of workload for doing this.
  2. Ranger is a memory killer, I don't think it can handle it perfectly as robust as a server in daemon mode.

I don't recommend doing this. TBH, the code quality of Ranger is not good enough, not enough to become a service.

amerlyq commented 2 years ago

I see. Having eternal ranger is definitely a subpar solution from the stability standpoint. Still I can devise systemd unit with memory limitations and restarting on crash -- which would be acceptable at least for me.

By the way (1) I didn't meant "tmux native floating windows" -- I expected your codebase will behave the same way, as it currently does, but instead of running termopen(ranger --config) you would run termopen(tmux attach-session -t rnvimr) each time you wish to open the window.

Moreover, this solution can even be generalized -- basically splitting your plugin into two.

One part -- to open/hide floating window with termopen(any_user_cmd), as fast as possible. Which will allow to have basically any other filemanager (and not only them) to be launched in the background in the same way. However other filemanagers (beside rnvimr) would need to use nvr to open files in the caller nvim instance instead of nested one.

Another part -- to run rnvimr itself, as a nicely adjusted experience for nvim with all the patches.

Considering only simple replacement of "ranger --config" by "tmux attach" in your codebase and fixing codebase to stop reading vim variables -- the idea is still unreasonable or not? Do you see any other problems?

kevinhwang91 commented 2 years ago

It's not easy to make rnvimr to adjust the generalized solution, maybe rebuilding a new plugin is a better solution.

Using bare nvr to communicate between nvim and the external process can't get a good user experience that the reason I creat this plugin. Ranger is wroten by python which is easy to hack, I think this way is the most cost-effective for Ranger.

Other FM need to open API to developers to get a better experience, IMO.

amerlyq commented 2 years ago

Ok, reasonable thoughts. You may close this issue, as creating a global service based on rnvimr currently seems unfeasible.