feat: fps mode

[tjdevries]

This might actually work. This moves to refresh-rate based redrawing of the screen.

Next up I want to do smarter redrawing and probably some other stuff too, but this actually seems to work well (except for occaisional flickers that I want to try and fix)

• [ ] Document how to use testing framework

[tjdevries]

If we can get this to work, then we would be able to move to different style of data structure for storing entries I think, which would be pretty cool

[tjdevries]

@l-kershaw I think I will re-implement some of the caret stuff. In the last commit, you can actually see how in highlighter.lua I am using:

  a.nvim_buf_set_extmark(results_bufnr, ns_telescope_selection, row, 0, {
    virt_text = { { caret, "TelescopeSelectionCaret" } },
    virt_text_pos = "overlay",
    end_col = #caret,
    hl_group = "TelescopeSelectionCaret",
    priority = SELECTION_HIGHLIGHTS_PRIORITY,
    strict = true,
  })

We can set the virt text here, instead of doing string mangling. Perhaps this will make things much easier to do than a bunch of string manipulation all the time. I might not be able to find all the references in this PR but I wanted to mention it to you since you were in chat today saying something about some of the prefix stuff.

[tjdevries]

at some point, perhaps we can even use "anti-conceal" feature from bfredl to not do any string concat at all, but I think this is fine (it is just string concat for lines on screen -- and less so than what we were doing before) so I am not worried about it.

I just think it will allow us to easily manage adding and removing the icons and prefix without having to search for the text within the string. Just add/remove the appropriate extmarks and namespaces and that will be all done :)

[l-kershaw]

@tjdevries Yeh, I'm happy for the caret stuff to be refactored to use extmarks instead. It definitely seems like it would be simpler, as it is keeping the caret separate from the entry itself, so (like you said) less string manipulation. The implementation in hi_selection seems reasonable 👍

Ping me if you need anything on this 🙂

---

One thing I noticed is you are using the strict key for extmarks, which I think was only introduced recently, and breaks things on 0.6.1. Since you are only setting it to true (the default) you will probably be able to safely omit it.

[kkharji]

😭 sorting 14609 files

https://user-images.githubusercontent.com/65782666/155046901-820dbfe9-2466-43dc-977c-a0042a12b614.mov ~~see when I type packlist, it stop for few seconds, this is always my case while searching. will this pr be a possible fix?~~

Oh nvm, it does fixed it, good looking @tjdevries ❤️

[tjdevries]

what? @tami5

[kkharji]

what? @tami5

I'm just facing issue with sorting 14609 files on master and I wondered if this PR solves it. And indeed it does in some ways, like before I had to wait for a second or two to get my wanted result. Though I notice that maybe highlighting is slower than before.

[fdschmidt93]

Just gave this a whirl as well. Looking great so far :)

• Speed is improved a lot, sorting 80K results (one_shot_job) vis-a-vis master is already improved by a landslide
• Almost usable with Telescope grep_string on 620K lines, much more non-blocking overall
• Highlighting is indeed slower (noticeable when adding/removing an extra character to the last say 1K results)
• Devicons are only highlighted if I scroll to the corresponding file?
• Scrolling can freeze on seeming large search? It's fixed by adding/removing a char. More specifically, some searches seem to move selection to bottom of visible results, where selection freezes. Can happen often, but don't have an immediate reliable repro.

[max397574]

any updates on this?

[luan]

@tjdevries is this still planned? I am running into a bunch of the other issues that mention this PR, but maybe y'all have moved on from this?

[liujoey]

waiting for this