The cursor moves to nvim-cmp and buffers when editing the commandline

[fredizzimo]

When editing the command line, the cursor often jumps to nvim-cmp windows and to main buffers, usually first to the completion popup, and when that's closed to the main buffer.

We can see the following in the log

TRACE [neovide::channel_utils] neovim_handler ModeChange { mode: Unknown("cmdline_insert"), mode_index: 5 }

And then later:

TRACE [neovide::channel_utils] neovim_handler CursorGoto { grid: 5, row: 0, column: 0 }
TRACE [neovide::channel_utils] neovim_handler Flush
TRACE [neovide::editor] Cursor unexpectedly sent to message buffer 5 (0, 0)

This bug is similar to

• Cursor Lagging behind when entering Command mode from Visual mode #2206
• No cursor movement when entering command via mapping #2376

The second one actually has the same cause as this, we don't detect all these modes as commandline modes:

• cmdline_normal,
• cmdline_insert,
• cmdline_replace

But due to the first problem and also to prevent temporary flickering, we might have to come up with something better. Although I don't know if that is possible without introducing extra lag.

This only seem to happen with Neovim nightly, mabye becuase it adds more sporadic movements, the additional modes have been there for a long time.

[bassamsdata]

I encountered a similar issue with mini.clue. Instead of staying in the buffer, the cursor moves to the next clue window. Pressing the leader key doesn't move the cursor, but pressing any other key that reveals mini.clue window, moves the cursor there.

It happened in mini.pick (fuzzy finder like telescope) as well, usually the cursor stays in the statusline, but now it jumps to the window of mini.pick

This behavior doesn't occur in Neovim (terminal), and it's specific to the nightly version, 0.10.

NVIM v0.10.0-dev-2819+gf4df49a95
Macos 13.6.6

thank you

Kapture.2024-04-06.at.11.13.06.mp4

[fredizzimo]

That's pretty bad, and unlike the original reported bug, I don't think we can do anything about it on the Neovide side. I will try to repeat it, get a proper log and report it to Neovim later today.

[fredizzimo]

I was just going to report this to Neovim, but I noticed that it happens in the terminal mode as well, with the following steps

1. create a file cursor_move.lua

-- Run this file as `neovide --neovim-bin path/to/nvim -- --clean -u cursor_move.lua`

for name, url in pairs {
    mini_clue = "https://github.com/echasnovski/mini.clue",
} do
  local install_path = vim.fn.fnamemodify("cursor_move_bug/" .. name, ":p")
  if vim.fn.isdirectory(install_path) == 0 then
    vim.fn.system { "git", "clone", "--depth=1", url, install_path }
  end
  vim.opt.runtimepath:append(install_path)
end

vim.opt.number=true
vim.g.mapleader = " "
vim.keymap.set("n", "<leader>aa", function() print("a") end, {desc = "aa"})
vim.keymap.set("n", "<leader>ab", function() print("b") end, {desc = "ab"})

local miniclue = require("mini.clue")
miniclue.setup({
    triggers = {
        { mode = "n", keys = "<leader>" },
    },
})

2 launch it using neovide --neovim-bin path/to/nvim -- --clean -u cursor_move.lua or neovim-bin path/to/nvim --clean -u cursor_move.lua
3. Press space and wait for the menu
4. Press a

Observe that the cursor moves to the line number column at step 3 and to the menu at step 4. In the terminal the cursor don't move to the line number, but it moves to the menu.

@bassamsdata, Can you repeat this as well?

I also bisected it down to this PR:
neovim/neovim#27858

That PR also causes the movements to the menu that I reported as the original issue, but that could be argued to be a Neovide bug, since we don't respect the movement request back to the command line. Although in my opinion the cursor should never move to somewhere else than what's being edited. There are a couple of other similar issues open:

• Cursor moves to commandline when printing message after writing file (perceived as cursor flicker) neovim/neovim#25974
• Cursor moves to commandline when searching for pattern (perceived as cursor flicker) neovim/neovim#25980

I'm waiting with the Neovim report until we have more details.

@echasnovski, if you are reading this, what's the expected behaviour?

[fredizzimo]

The original bug can indeed be fixed by handling the other command line modes as suggested in the initial message. So it remains to see if the mini.clue bug should be fixed in Neovim or mini.clue

[bassamsdata]

Hey @fredizzimo, thanks for the detailed response and the repro. I can confirm that the issue occurs in Neovim's terminal mode and also in Neovide with the minimal repro case.

I hadn't planned to report it initially, but the issue is quite disruptive, especially because the code is on the left and mini.clue appears on the right, making the cursor movement very noticeable.

[echasnovski]

Observe that the cursor moves to the line number column at step 3 and to the menu at step 4. In the terminal the cursor don't move to the line number, but it moves to the menu.

I can reproduce on latest Nightly as well. Cursor should never move to the clue window. But I have a bad feeling that this might not have a good resolution because 'mini.clue' (same as also mentioned 'mini.pick') works by leveraging getchar() (or getcharstr() to be precise) and how cursor behaves during it is not controllable.

I'll take a closer look.

[fredizzimo]

@echasnovski, thanks. It looks like what caused the bug in the first place:

• fix(ui): issues controlling cursor position with ext_cmdline neovim/neovim#27858

Would also let you to control the cursor position during the call, if I'm understanding it correctly.

[echasnovski]

This indeed looks like a result of neovim/neovim#27858 (more likely this commit in particular). The likely reason this happens is described in this comment. From 'mini.clue' side I have not much left to do because any other alternative solutions which not use nvim_win_set_cursor() don't work for various other reasons. The only solution would be to redesign the whole module to use new buffers for every suggestions, but I don't think it is reasonable to do just for this type of "inconvenience" issue.

[fredizzimo]

Thank you. It looks like it's getting reverted here:

• fix(api): do not update grid position in nvim_win_set_cursor neovim/neovim#28235