mikavilpas / yazi.nvim

A Neovim Plugin for the yazi terminal file manager
MIT License
214 stars 7 forks source link

Bulk renaming is broken #135

Open syhol opened 1 week ago

syhol commented 1 week ago

https://github.com/mikavilpas/yazi.nvim/assets/642428/006b392a-f44a-43f8-b219-bcc1d683a733

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 commented 1 week ago

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 https://github.com/sxyazi/yazi/issues/989 - you can track that issue if you're interested.

Let's keep this issue open!

mikavilpas commented 2 days ago

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 https://github.com/mikavilpas/yazi.nvim/pull/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 commented 1 day ago

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 commented 1 day ago

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 commented 1 day ago

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