[Feature] Add support to change / close vim buffers when corresponding files are renamed / removed by vifm?

[Bekaboo]

Hi, first of all, thank you for making this awesome plugin!

I discovered this plugins several days ago, before that I use rnvimr as my file manager inside nvim and now I'm planning to switch to this one since vifm's keymaps and commands makes more sense to me.

However, there's a feature that I miss from rnvimr, that is automatic buffer reloading when the corresponding file is renamed / moved / removed by the file manager. I don't know if I'm doing it wrong or I mis-configured vifm.vim, but if I renamed or moved some files using vifm.vim, the buffer in nvim will not change and nvim warns me about the disappearance of the corresponding file. In general this makes me feel like vifm.vim is more like a file "picker" instead of a file manager that have a deeper integration with the editor itself, and making file renaming / moving clunky inside vim/nvim.

Is there any plan to improve file renaming / moving experience in vifm.vim? Thanks again!

[xaizek]

Hello.

You're right about this being primarily a file picker rather than a merging of a file manager into an editor. File picking is the primary use, but extensions are still possible, although having deep integration into both Vim and NeoVim is not convenient.

Renaming buffers on file operations were never considered before and require a communication channel with the editor as well as notifications about file operations. reveal.nvim plugin is closer to this and is probably more native to NeoVim than this will ever be. Although Vifm's Lua interface currently lacks notifications about operations, I wonder whether @haolian9 would want to implement a feature like this in his plugin? Adding new event to Vifm's Lua API for renames/moves shouldn't be hard.

[Bekaboo]

Thanks for your reply.

Although Vifm's Lua interface currently lacks notifications about operations

Does that mean a modification is needed in Vifm's souce code?

[xaizek]

Does that mean a modification is needed in Vifm's souce code?

Yes.

[Bekaboo]

Thank you, please consider adding that feature to vifm! It will be amazing if we could make vifm more integrated into vim/nvim.

[haolian9]

Hi, reveal.nvim uses a named pipe to communicate between nvim and vifm, it can handle vifm event in nvim, but honestly i dont know how to handle this renaming event properly in nvim.

here are some of my doubts on implementing the handler at the very first thinking:

• maybe vim itself want to handle this by adding a new option? the similar option in vim is &autoread, and it's for content changing outside of vim.
• seems there is no reliable or cheap api for buffer renaming in nvim: https://github.com/neovim/neovim/issues/20349. (cheap againsts the buffer duplicating in nvim_buf_set_name, reliable againsts the setfname ffi call)
• if we found out the way to rename vim buffer, do we need a global option just like &autoread?
  • or prompt user to confirm each renaming operation in nvim while user is inside vifm? (IIRC, that's how nerdtree handles file renaming and deleting)
  • if so, how do we show the confirm prompt? using a higher z-index nvim float win or a confirm prompt from vifm

[Bekaboo]

Hi, reveal.nvim uses a named pipe to communicate between nvim and vifm, it can handle vifm event in nvim, but honestly i dont know how to handle this renaming event properly in nvim.

Maybe we can refer to rnvimr and see how it tackle with the problem? It uses RPC and pynvim for communication, though.

[haolian9]

regarding "maybe vim itself want to handle this by adding a new option?" another approach could be: nvim employs a process that runs on inotify and syncs the filesystem changes back to nvim's buffer. this is a more general way to get the renaming event, not bound to any specific file manager, and not requiring changes nor exposing apis on file manager side. if nvim is not going to accept this feature request, in user land we can still using a) luajit ffi lib to use the inotify lib b) spawning inotifywait -m c) even better, libuv provides fs events.

[xaizek]

regarding "maybe vim itself want to handle this by adding a new option?"

I don't think this will work well. man inotify:

       IN_MOVE_SELF
              Watched file/directory was itself moved.

       IN_MOVED_FROM (+)
              Generated for the directory containing the old filename when a file is renamed.

       IN_MOVED_TO (+)
              Generated for the directory containing the new filename when a file is renamed.

You get new path (the name part) only from IN_MOVED_TO, which can be any directory. Meaning that you'll have to watch all possible destinations and probably monitor mounts. Even if inotify descriptors won't run out by tweaking their limit in the kernel, many millions of them will be kept in the kernel and managed in user space for nothing.

[haolian9]

ah, nice to know that, I was naive on using inotify. then I think this "adding new vifm event" approach is more straightforward, and I'd like to implement a default handler in reveal.nvim. Though I dont think reveal.nvim can be an alternative to vifm.vim, and that's why I had not named it as vifm.nvim :).

---

I forgot to mention how rnvimr implemented this feature: it stores the buffer list before starting ranger and bwipes the buffers have been renamed/deleted when ranger window closed. IMO, this could be the way vifm.vim can take.

[xaizek]

I forgot to mention how rnvimr implemented this feature: it stores the buffer list before starting ranger and bwipes the buffers have been renamed/deleted when ranger window closed. IMO, this could be the way vifm.vim can take.

Nice, thanks :) I incorrectly assumed that RPC was used for this. I also missed that renaming can be handled by just closing the buffer to not annoy the user with the messages.

New Lua event for this should be easy to add at least for these operations, so that can be added too. I thought about your plugin because I remember that it keeps single instance of Vifm running in which case notifications seem like the way to do this.

[haolian9]

Speaking of RPC, I recently (yesterday, coincidentally, and @xaizek pobably already) learnt that vim provides :h terminal-api which let the process runs in vim's builtin terminal able to speak to vim. With this, maybe vifm.vim can also make use of these new lua events as long as vifm.vim including a lua plugin to do that. But unfortunatetely there is no equilevant api in neovim (yet i think it's possible to be implemented *1).

*1

```lua nvim_open_term(on_input = function(event, term, bufnr, data) -- processing the data comes from vifm if "vifm wants talk to us" then -- we are listening and able to do something for him. else vim.fn.chansend(chan, data) end end) ```

[xaizek]

Yeah, I like the idea of terminal API in Vim, but yet to see an equivalent in NeoVim. Not sure if on_input can work (it might be targetting CLI applications), because terminal processing needs to somehow differentiate regular TUI drawing from the API, hence Vim's use of an escape sequence which is probably handled in pseudo-terminal code.