[mini.jump] Breaks dot-repeat when jumping between repeats

[toupeira]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version of the main branch

Module(s)

mini.jump

Neovim version

0.11.x

Description

When dot-repeating a command which includes a jump (e.g. dt]), and using a different jump between repeats, the original jump is lost and instead the other jump is repeated.

This works correctly with mini.jump disabled.

Reproduction

1. Create separate 'nvim-repro' config directory:

   • '~/.config/nvim-repro/' on Unix
   • '~/AppData/Local/nvim-repro/' on Windows

2. Inside 'nvim-repro' directory create a file named 'init.lua'.
   Populate it with the following content:

   -- Clone latest 'mini.nvim' (requires Git CLI installed)
   vim.cmd('echo "Installing `mini.nvim`" | redraw')
   local mini_path = vim.fn.stdpath('data') .. '/site/pack/deps/start/mini.nvim'
   local clone_cmd = { 'git', 'clone', '--depth=1', 'https://github.com/nvim-mini/mini.nvim', mini_path }
   vim.fn.system(clone_cmd)
   vim.cmd('echo "`mini.nvim` is installed" | redraw')
   
   -- Make sure 'mini.nvim' is available
   vim.cmd('packadd mini.nvim')
   require('mini.deps').setup()
   
   -- Add extra setup steps needed to reproduce the behavior
   require('mini.jump').setup()

3. Run NVIM_APPNAME=nvim-repro nvim (i.e. execute nvim with NVIM_APPNAME environment variable set to "nvim-repro").
   Wait for all dependencies to install.

4. Enter the following text:

   [foo, 1]
   [foo, 2]
   [foo, 3]
   

5. Move to the beginning of the file: gg0

6. Search for foo: /foo<CR>

7. Jump to the first comma: f,

8. Delete until the closing bracket: dt]

9. Go to the next search result and jump to the second comma: nf,

10. Repeat the deletion: .

Expected result: Everything up to the next closing bracket should get deleted:

[foo]
[foo]
[foo, 3]

Actual result: Everything up to the next comma gets deleted instead:

[foo]
[foo, 3]

[echasnovski]

Thanks for the issue!

I indeed can reproduce. To be perfectly honest, I was a bit surprised to see that built-in ftFT jumping in Operator-pending mode behaves like that. I guess it makes sense because dt] was explicit. The current behavior of 'mini.jump' was intentional and always made sense to me since its jumping is more "stateful" (i.e. it tries to use latest jump state more than built-in).

Interestingly enough, the built-in behavior for ; is like in 'mini.jump'. The d; uses the latest ftFT jump target, even if it changed. Which probably also makes sense.

I'll take some time to think if supporting this behavior is reasonable for 'mini.jump'.

[toupeira]

Thanks, that's fair!

FWIW this does trip me up quite often, and it definitely seem "wrong" to me that the jump target from the repeated dt] is just ignored like that.