Pick grep_live puts me in wrong lineno for new buffers

[aorith]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.pick

Question

Hi!

I'm not sure when this started happening, but currently I'm on 0.12.4 and using this configuration: https://github.com/aorith/neovim-flake/tree/master/nvim

If I open neovim and do a Pick grep_live search (I have it mapped to space + fg), then I search for something, for example "transparency" which has a single match... Instead of going to the line 219 of nvim/init.lua the cursor stays at line 28 (I have seen it sometimes on line 40)

It is really weird. I tried disabling an autocmd to restore the last cursor position which I had for a looong time, but that didn't solve it, also AFAIK mini.pick changes the cursor synchronously after that.

Then I started disabling other plugins too... without success.

I'm not sure what is going anymore!
Does anyone have an idea?

[aorith]

Uhm ok, I think that I found what is causing the issue, if I disable this line I cannot reproduce the issue anymore: https://github.com/aorith/neovim-flake/blob/424e610ba533f35cff8503aae551e671489afb9f/nvim/plugin/11_mini.lua#L4

Anyone else experiencing this?

[echasnovski]

This sounds strange and I indeed can reproduce with the following minimized setup:

• Use clean repro config with this init.lua:

  vim.o.splitkeep = 'screen'
  vim.o.showtabline = 2
  vim.pack.add({ 'https://github.com/nvim-mini/mini.nvim' })
  require('mini.pick').setup()

• At the root of https://github.com/aorith/neovim-flake execute :Pick grep pattern='misc' and choose the only match in nvim/plugin/99_mappings.lua on line 195. It will open the file but put cursor on line 56. Similar behavior for pattern='Transparency' and the same line 56, which is somewhat close (but not quite) to the actual height of the Neovim instance.

I haven't yet been able to localize this further. Will take a look later.

[echasnovski]

Okay, it was very much an advanced exercise of figuring out a minimal reproduction example. This resulted in neovim/neovim#40964.

I'll wait a bit for what upstream will do here, but everything points out that this is not a 'mini.pick' issue. And although it (probably) can account for it, I'd rather have this fixed upstream and point users to the new Neovim version.