jake-stewart / multicursor.nvim

multiple cursors in neovim
MIT License
574 stars 4 forks source link

mc.action gets dropped in ex commands #31

Closed ajvondrak closed 1 week ago

ajvondrak commented 1 week ago

Config:

{
  "jake-stewart/multicursor.nvim",
  commit = "9f8a480",
  config = function()
    local mc = require("multicursor-nvim")

    mc.setup()

    vim.keymap.set("n", "x", function()
      print("Running action")
      mc.action(function(ctx)
        print("  action!")
      end)
      print("Ran action")
    end)

    vim.api.nvim_create_user_command("X", function()
      print("Running action")
      mc.action(function(ctx)
        print("  action?")
      end)
      print("Ran action")
    end, {})

    vim.api.nvim_create_user_command("Scheduled", function()
      print("Scheduling action")
      vim.schedule(function()
        mc.action(function(ctx)
          print("ran action!")
        end)
      end)
      print("Scheduled action")
    end, {})
  end,
}

When pressing the custom x mapping in normal mode, :messages reads as expected:

Running action
  action!
Ran action

However, :normal x silently fails to execute the action:

Running action
Ran action

This is also the case if we run the same basic code through a custom user command, :X in the above config:

Running action
Ran action

The only thing I can think to do is vim.schedule the mc.action so that it triggers asynchronously after the ex command is finished. So with the :Scheduled user command above:

Scheduling action
Scheduled action
ran action!

Is there anything smarter mc.action could do? I think ex commands are explicitly being short-circuited by this condition: https://github.com/jake-stewart/multicursor.nvim/blob/f68e66cb9d490662571f664c313b6eeca774b25a/lua/multicursor-nvim/input-manager.lua#L57-L59 I assume that's there so that when you're on the ex command line typing things, it doesn't feed input into the multicursors. But I'm also guessing self._cmdType remains truthy even after I hit <cr> and start executing my command that winds up trying to trigger the mc.action. I don't know enough about the control flow here to hazard a guess at any fixes, though.

jake-stewart commented 1 week ago

It looks like we can just get rid of that code.

 if self._applying or self._inInsertMode or self._cmdType then 
     return nil 
 end

Everything seems to work without it.