File picker does not match all files about helix HOT 10 CLOSED

Since we use skim's matching algorithms it might be worth figuring out how skim does this for it's interactive mode.

from helix.

Seems to be reasonably solved by #171 and #187 ?

from helix.

The problem I see with passing an iterator through: you can only consume it once then we'd need to construct a new one which would re-query the file system.

As a quick fix we could significantly raise the limit? I just primarily wanted to avoid someone using this on something like / and crashing.

from helix.

There is many ways to solve this. A compromise solution could be to search enough to fill the screen (like the first 20 files) and keep the iterator for future search. The previous results can be cached.

The drawback is when the user deletes what he was searching a new iterator needs to be created.

from helix.

I downloaded skim and launch the command from $HOME, $ sk.

$ ps aux | grep -E '^USER|sk$' 
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
begin    3129735 90.6  2.9 1509812 230360 pts/7  Sl+  11:08   9:46 sk

from helix.

I tried on macOS as well.

~ $ sk

~ $ ps -O %mem  -p 57760
  PID %MEM   TT  STAT      TIME COMMAND
57760  0.2 s002  S+     0:47.79 sk

Translates to roughly 267MB on my machine.

from helix.

I looked a bit into skim and I think it does a lot more. Like it does rayon to parallelize search. I wonder if @lotabout have any suggestions how we can integrate it here since we have to display it on a certain rectangle, we may also need to have the ability to do extra filtering later on.

from helix.

Oh I don't think we need to embed skim, my thought was since we use the fuzzy-matcher crate which was built for skim there might be something we can learn from the implementation.

from helix.

seems to me that this could be closed...

from helix.

Agreed, please reopen if you still encounter this problem.

from helix.