fix(jump): jump sometimes highlights after jumping has stopped

[abeldekat]

Details:

• As a side-effect of the jump, a function is scheduled that will trigger a BufLeave event

• After the jump, a function is scheduled immediately that will run H.highlight(0 delay.highlight)

On BufLeave, MiniJump.stop_jumping is called.
That will stop H.timers.highlight. However, the timer already scheduled the function.
Thus, H.highlight runs and applies the highlighting, although state.jumping is false.

This PR adds an extra early return to H.highlight

Resolve #2318

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

[echasnovski]

Thanks for the issue!

• As a side-effect of the jump, a function is scheduled that will trigger a BufLeave event

If that is the 'mini.files' behavior (which from 2318 it probably is), then it should be fixed on 'mini.files' side. That should not happen.

But even with the change from this PR I still don't have "smart jumping" work in 'mini.files'. Which is strange and needs extra attention.

[abeldekat]

Thanks for the issue!

• As a side-effect of the jump, a function is scheduled that will trigger a BufLeave event

If that is the 'mini.files' behavior (which from 2318 it probably is), then it should be fixed on 'mini.files' side. That should not happen.

But even with the change from this PR I still don't have "smart jumping" work in 'mini.files'. Which is strange and needs extra attention.

Yes it is, on CursorMoved. This PR does not repair smart jumping, it merely prevents the suggestion that it's possible(by highlighting) when it is not.

The problem is the file preview. On each change, MiniFiles emits BufLeave. That prevents smart jumping.

[echasnovski]

The original 'mini.files' issue should be soon resolved, but I think checking jumping when attempting to highlight makes sense. Merged into a temporary branch to quickly adjust myself.

[abeldekat]

The original 'mini.files' issue should be soon resolved, but I think checking jumping when attempting to highlight makes sense. Merged into a temporary branch to quickly adjust myself.

Great!
I was also thinking: Would it be possible to only react on BufLeave if that event is triggered for the buffer the user "is busy with"? Other BufLeave, like the ones from mini.files preview, are not relevant perhaps.

[echasnovski]

I was also thinking: Would it be possible to only react on BufLeave if that event is triggered for the buffer the user "is busy with"? Other BufLeave, like the ones from mini.files preview, are not relevant perhaps.

Yeah, that is a good idea. Should be part of the main now.

Through trial and error in other modules, there is a more or less established in 'mini.nvim' approach for creating an autocommand for interactive feature that should only be executed in the current buffer: vim.schedule_wrap(function(ev) if ev.buf == vim.api.nvim_get_current_buf() then ... end end).

[abeldekat]

Super!