Experience weird behaviour with mini.jump

[megalithic]

Anyone else experiencing randomly breaking behaviour in mini.jump where you might df(, once or twice, then on the third time, it "undos" previous behaviour and also breaks other UI/highlighting behaviour?

Here's a loom to illustrate, wasn't sure how to describe it:
https://www.loom.com/share/33244493ef914e9e9109d19964fb1e1f

Thanks!

[echasnovski]

Very strange indeed.
Couple of thoughts:

1. That kind of statusline (default builtin) usually appears when some Lua code has gone wrong.
2. Does this happen when you press dot to repeat it instead of a new df)?
3. Do you have any other plugin installed which might alter the df)? One way to check is to type omap f in Command line. It should give the MiniJump function.
4. The usual way to debug this is a good old "half the config and try reproduce". If you can reproduce this with only 'mini.jump', then it is a problem with it only. If not - then it is some kind of interference issue with other plugin. Either way, if you can achieve stable reproducible example of this, I'd be super curious to see it.
5. Usual questions: which Neovim version you are using and is config public?

[megalithic]

UGH, i spoke way too soon :( will debug further sigh i want mini.jump so bad.

[megalithic]

Also, I had begun filling out an issue for this yesterday, (the reason I recorded the Loom), but to be honest, it is something that just seemingly randomly started happening and i had checked through my changes. :/

answers:

• nvim --version: NVIM v0.8.0-dev-745-g7f4c50f8c
• dots

Anyway, GREAT news, i found the offending plugin: fidget.nvim; which is a shame, i very much appreciate the lsp feedback :/

[echasnovski]

I have literally no idea why 'fidget.nvim' might have a conflict particularly with 'mini.jump'. I am able to replicate though. Will look into it.

[echasnovski]

So I've got to the bottom of this and created an issue in 'fidget.nvim'. This is not the first time it has encountered this type of issue: it also happened for 'clever-f'.

The reason seems to be quite complex. The 'fidget.nvim' is doing asynchronous update of lines in its window (as it is expected to do). It is wrapped in vim.schedule() (how it is supposed to be done). However, if getchar() is called inside expression mapping, it blocks Neovim while still trying to execute all asynchronous calls. This results in error, because text can't be changed when Neovim is blocked. This error manifests itself in disabling lua statusline and perform undo on current buffer (no idea why this specifically is done). Honestly, it does seem like an issue on Neovim part.

Unfortunately, both expression mapping and getchar() is crucial to 'mini.jump' (and "user prompt" textobject from 'mini.ai' in Operator-pending mode, for that matter) as it allows dot-repeat without re-asking for user input.

Fortunately, this seems to be an issue only if 'fidget.nvim' is actively updating its window. Otherwise, they should co-exist without (obvious) problems.

All in all, thanks for an interesting case!

[megalithic]

Wow, THANK YOU for such deep investigative work on this. Debugging can be fun (not sure if this was fun for you, though, lol). While fidget was/is nice for lsp feedback, it's not crucial to workflow like many of the mini plugins in your suite of plugins are for my day-to-day development. I appreciate you filing an issue for this, though! Glad I could provide a brief detour into inter-plugin madness. 🤣