Directory scan order and dynamically show results

[andreikop]

showing FuzzyOpener content even before everything is scanned + scan directories in complicated, weighted order (important first, supplementary second).

For example, if I have files opened:

/home/vi/code/myproject1/src/1.cpp /home/vi/code/myproject1/src/2.cpp /home/vi/code/myproject1/src/3.c /home/vi/code/myproject1/Makefile /usr/share/doc/somelib/index.html /usr/share/doc/somelib/types.html /tmp/stacktrace.txt Then I expect /home/vi/code/myproject1/src and *.cpp files to have maximum weight and scanned first. But /usr/share/doc/somelib/ may also appear (scanned later and skipped if it is too big, i.e. low prio).

By @vi

[andreikop]

Laptop produced in 2007 with Hard disk scans the Linux kernel sources in 8 seconds. FS tree is not cached, I made an experiment just after a reboot. Second scan takes 4 seconds. And it will be quicker on a modern PC. I think it is good enough to leave as is.

[vi]

Does 8 seconds hold even after echo 1 > /proc/sys/vm/drop_caches?

When directory entries are already in memory I expect the scanning to be reasonably fast in any case.

This issue is not a priority one anyways.

[andreikop]

I rebooted my laptop just before testing to have as precise results as possible.

[vi]

Tried scanning files on Linux source tree. It spanned a minute (about 57 seconds) and found 66k files. Closing Enki and re-scanning again (from cache) took 4 seconds.

I suggest to extend "Scanning %s: %d files found" message with notes about aborting scanning and about using deterministic opener.

Something like this:

Scanning linux: 40123 files found.
Press Esc to abort scanning.
Use "./<what_user_has_already_typed_so_far>" or "f ..." to open file bypassing this scan.
Use "scan" Locator command to start background scanning.

The "scan Locator command" is up to discussion. It may be a menu entry. Or it may be just p . (which may trigger background scanning).

[andreikop]

It makes sense

[andreikop]

Scan command is done