You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's definitely great to support more fuzzy filter mode on the strength of the existing fuzzy finder tools, e.g., fzy, fzf, skim. It's trivial to feed the input into these tools by using system(), but it's sync, I'm not quite a fan of this way. So the first thing is to support filtering in async, even for the sync provider. If you use the external tools for the fuzzy filter job, it has to be async. And then we could integrate the existing fuzzy finders.
The problems:
The query is possibly unable to be highlighted in vim-clap as there is no way to know which part of the query should be highlighted. If the fuzzy finder could return the matched position, then the highlights are possible.
It's unavoidable to use some shell commands, which can't work in Windows.
Using job to run in async will cause a redraw, but the redraw won't happen for sync run, which is more eye friendly.
Due to these problems, I personally still prefer these sync providers' source not huge to use the sync fuzzy filter, which could use Python, Lua or any other language based tools. For the sync provider monsters(having +10,000 or 100, 000 items, needs to be investigated), the async filter could be used.
However, for some providers, it's impossible to know the items count ahead, e.g, :Clap files which actually uses rg --files etc, if you run from a directory containing too many items, let's say the home direcotry that normally has over 800,000+ files in my case, vim-clap becomes less responsive, which could be improved of source. But the performance optimization will be later.
The text was updated successfully, but these errors were encountered:
This issue is addressed by #18. Now it's easy to introduce new external fuzzy filters(#18 already has fzy and fzf) and run everywhere async. I think it's already great, but not perfect, which is able to match the highlighted parts as well as to do fuzzy filter in async way. That's not an easy job though. Let people pay with the current version and improve it later. Feel free to create another issue if you want to see more fuzzy filters support or have any ideas about this.
It's definitely great to support more fuzzy filter mode on the strength of the existing fuzzy finder tools, e.g., fzy, fzf, skim. It's trivial to feed the input into these tools by using
system()
, but it's sync, I'm not quite a fan of this way. So the first thing is to support filtering in async, even for the sync provider. If you use the external tools for the fuzzy filter job, it has to be async. And then we could integrate the existing fuzzy finders.The problems:
It's unavoidable to use some shell commands, which can't work in Windows.Due to these problems, I personally still prefer these sync providers' source not huge to use the sync fuzzy filter, which could use Python, Lua or any other language based tools. For the sync provider monsters(having +10,000 or 100, 000 items, needs to be investigated), the async filter could be used.
However, for some providers, it's impossible to know the items count ahead, e.g,
:Clap files
which actually usesrg --files
etc, if you run from a directory containing too many items, let's say the home direcotry that normally has over 800,000+ files in my case, vim-clap becomes less responsive, which could be improved of source. But the performance optimization will be later.The text was updated successfully, but these errors were encountered: