Fuzzy cache

[bjones1]

I found a couple of problems with the fuzzy opener:

1. I wanted to open a file, but found results from Sphinx's _build directory. I added that to the list of ignores, then ran the opener again -- no change. Closing and restarting Enki fixed the problem. I assume the list of found files wasn't cleared/updated when I updated the ignores in the settings dialog.
2. I used git to check out a new branch, but the fuzzy opener didn't know about the newly created files in this branch. Again, closing and re-opening fixed the problem. I assume the opener isn't monitoring filesystem changes or something similar.

[andreikop]

I'll add "scan" locator command or the first release.

Autorescan is very difficult question. It is impossible to effectively monitor big file system tree. If I scan the file system on timer, @vi would shout "Stop trashing my old Hard DD". And would have some reason. It is especially bad to keep HDD rotating and CPU working on laptops which work on a battery.

Probably it is impossible to invent some hacks, will think about it in the future. Suggestions are welcome.

[bjones1]

I agree that large filesystems are hard to monitor. But, at the same time, aren't you doing this already in the file browser? If I add / delete a file, I see the update appear in Enki without any reload...

...of course, I'm not sure if that still works on a large filesystem...

QFileSystemWatcher? Or perhaps an option to rescan?

[vi]

1. I expect explicit "scan" command issued again to rescan directory;
2. I expect files opened or created by ./deterministic ./opener to be available to fuzzy opener without rescanning. Including normally ignored *.o, *.class files.
3. If nothing is found (or relevance falls below some thresholder), a message to user mentioning ignored files or rescan option should be displayed.

[vi]

I'll add "scan" locator command or the first release.

Is making p . a [re-]scan command a good idea? Re-specify project to the same directory == rescan.

[andreikop]

I've added scan command

[andreikop]

QFileSystemWatcher docs:

The act of monitoring files and directories for modifications consumes system resources. This implies there is a limit to the number of files and directories your process can monitor simultaneously. On Mac OS X 10.4 and all BSD variants, for example, an open file descriptor is required for each monitored file. Some system limits the number of open file descriptors to 256 by default. This means that addPath() and addPaths() will fail if your process tries to add more than 256 files or directories to the file system monitor. Also note that your process may have other file descriptors open in addition to the ones for files being monitored, and these other open descriptors also count in the total. Mac OS X 10.5 and up use a different backend and do not suffer from this issue.

I guess Qt FS model (File Browser) monitors not whole tree, but only a few visible nodes.

[andreikop]

@vi, It is possible that an user tries to open already opened project. In this case I don't drop the list of files and scan again. Therefore I think it makes sense to just ignore p .. There is scan, I think it is enough.

Adding newly created files is a good idea. But, not in the first release. Who knows, probably some smart way to monitor or rescan the FS will be invented.

[vi]

I'm not sure if a bug, but feels little strange:

1. Open Enki in Linux tree
2. Open locator
3. Start typing scan

s

A list of top level files is shown. I don't know why. Maybe for the "save as" command?

sc

Scanning linux: 0 files found Scanning linux: 2253 files found

sca

Scanning linux: 8253 files found

scan

scan Scan (rescan) the project

(and the already started scan thrown away)

Not a big deal (since the directories are cached and rescanned very quickly), but still.

[andreikop]

Yes. s is recognized as Save As and sc like fuzzy open. I have some ideas how to solve this situation but for the first release leaving as is. Suggestions are welcome!