Add a next/prev_match version which does not re-apply highlight

[DrKGD]

Highlight is reapplied using documentation-like bindings and doesn't really exit from the sj-mode

vim.keymap.set("n", "<A-,>", function()
  sj.prev_match()
  if sj_cache.options.search_scope:match("^buffer") then
    vim.cmd("normal! zzzv")
  end
end)

vim.keymap.set("n", "<A-;>", function()
  sj.next_match()
  if sj_cache.options.search_scope:match("^buffer") then
    vim.cmd("normal! zzzv")
  end
end)

Fiddling with the exposed API, I found out that require('sj.ui').clear_feedbacks() does exactly what I want thus clears the highlight right after next/prev_match calls, but it redraws the screen for a frame or so, flickering on and off the highlight really quickly.

vim.keymap.set("n", "<A-;>", function()
  sj.next_match()
  if sj_cache.options.search_scope:match("^buffer") then
    ui.clear_feedbacks() end
end)

Is something funny going on or this is exactly what'd you expect with the usage proposed in the documentation? By the way, I really like this approach to jump around text, I tend to use the native vim search and replace commands to move around and I can't really get used to other similiar plugins with extremly smart features, but with sj.nvim I immediatly felt home 😊.

I am going to provide more info in case this IS indeed a bug on my side.

Versions NVIM: v0.9.0-dev-202+g19dab2ead SJ.nvim: 9bbb002

Describe the bug next/prev_match API calls turn on a persistent version of the highlighter, which goes away either when it expires (timeout) or when entering the command mode.

Expected behaviour Right after the next/prev_match API calls, the cursor is re-positioned at the previous/next match.

To Reproduce

1. Call any version of require('sj').run()
2. Select any result, thus quitting the sj-select-mode
3. Run next/prev_match

[woosaaahh]

When using sj.prev/next_match(), there is an autocmd that is supposed to clear the highlights on "CursorHold" (cursor stopped moving after few ms) and "ModeChanged".

Clearing the highlights just after using the keymap (as in your sample) might not be a solution.

Could you please try with the lastest commit from the branch 0.6 and tell me if you still have this issue ?

[DrKGD]

Uhm, it DOES clear on CursorHold, but it takes way too much time, like 5 seconds? Threshold is that high or something is acting up?

Both the main branch and the 0.6 branch behaves the same on the matter

[woosaaahh]

If you try :set updatetime? what does this output ? (The default value is 4000ms so 4s)

[DrKGD]

Nevermind, guess I am just being blind, it is actually stated in the documentation itself

...
highlights_timeout = 0, -- if > 0, wait for 'updatetime' + N ms to clear hightlights (sj.prev_match/sj.next_match)
...

It waits for updatetime, which defaults to 4000ms, so ... yeah. Setting both highlights_timeout and vim.opt.updatetime to very low threshold makes it behave like you stated.

[woosaaahh]

Can I close the issue ?

[DrKGD]

Sure! Sorry for the inconvenience 😔

[woosaaahh]

No problem at all ! That's what issues are made for ! :smile: