Bulk renaming is broken

[syhol]

Screen.Recording.2024-06-25.at.14.53.08.mov

Bulk renaming puts the window into a strange broken state and ctrl+c is the only way to break out of it. This works fine when I run yazi directly outside of of neovim.

Recreation steps:
Install Yazi, version: Yazi 0.2.5 (Homebrew 2024-04-23)
Install Neovim, version: NVIM v0.10.0 / Build type: Release / LuaJIT 2.1.1713773202
Setup the plugin with recommended settings, but changed opts.open_for_directories to true:

---@type LazySpec
return {
  'mikavilpas/yazi.nvim',
  dependencies = {
    'nvim-lua/plenary.nvim',
  },
  event = 'VeryLazy',
  keys = {
    -- 👇 in this section, choose your own keymappings!
    {
      '<leader>-',
      function()
        require('yazi').yazi()
      end,
      desc = 'Open the file manager',
    },
    {
      -- Open in the current working directory
      '<leader>cw',
      function()
        require('yazi').yazi(nil, vim.fn.getcwd())
      end,
      desc = "Open the file manager in nvim's working directory",
    },
  },
  ---@type YaziConfig
  opts = {
    open_for_directories = true,
  },
}

Open a new neovim session:
nvim .
Enter visual mode:
v
Rename:
r
Then it's in this stuck state.

[mikavilpas]

Hi! This is a known issue - for now this cannot be done in yazi.nvim.

I have laid out some plans for addressing this in sxyazi/yazi#989 - you can track that issue if you're interested.

Let's keep this issue open!

[mikavilpas]

I was able to implement a proof-of-concept for bulk renaming! It's still a bit work in progress, but can be tried out here #152

It currently requires a yazi version built from source along with its new ya command line helper application. I use ya to read events sent from yazi and eventually want to move to supporting only it, but I think I will have to maintain both the new ya approach and the current (hacky) approach separately so users have some time to move to the new system.

[mikavilpas]

It seems that currently the proof-of-concept in #152 can only work locally, but it can't work in continuous integration - the build system doesn't have easy access to the bleeding edge version of yazi. Right now on the master branch, the latest release of yazi is installed in CI, and this has worked well.

But the old tests were simple unit tests and basically only depended on the yazi application being found - it was never actually interacted with. With the recent addition of full integration tests, yazi.nvim now tests all interaction with yazi exactly as a user would, so all the tested features need to be available.

I think the simplest, fastest solution to this is to build (and cache) yazi from source in CI. This might be possible to remove once the next stable version of yazi is released.

[mikavilpas]

Although a bit more complicated, the building from source could also be done in yazi, and I could install a prebuilt binary for CI, e.g. with cargo-binstall.

@sxyazi I'm curious if you have given any thought to the possibility of building "nightly releases" in yazi.

[mikavilpas]

mini update: Building from source and caching seems to work! I used https://github.com/baptiste0928/cargo-install

[mikavilpas]

The feature is now ready to be tried out in #152

[sxyazi]

@sxyazi I'm curious if you have given any thought to the possibility of building "nightly releases" in yazi.

Yeah I'll give it a try, probably just need to make some little changes to the existing release workflow.