Menu
▾
▴
#156 SmartOpen: frequency buffer opening take into account
I have wroten an small patch, which accounts the frequency buffer
opening of particular files: the more frequent files are listed in the
top list...
It also disables the project update on the plugin start in case of file storage, because it resets all frequency
information.
Tested with: SmartOpen 1.1, jEdit 5.0
SmartOpen-1.1-account-frequency.patch (more accurate and error prone version)
Hi, your patch seems interesting, but I'm updating the Lucene plugin to Lucene 4.1 and the api is changed a little.
The trunk of Smartopen is updated for that but the patch do not apply.
I did a change that is minor for the plugin but cause problems for your feature: the index is now always in memory.
The problem is that the frequency will be lost after restarting jEdit, do you think it is a problem or is it acceptable ?
Hello Matthieu,
Yes, I know that in-memory Lucene's indices are lost after jEdit restart. But let it be decided by user weather store indices in-memory or on disk.
There is pros and cons on the in-memory storage engine:
Pros: a bit faster search and no disk memory usage (the last ins't real benefit, I think).
Cons: Usage statistics can't be persisted and a bit delayed startup or project switch (on large project the plugin re-indices whole project, which is a bit annoying).
Regarding disk storage engine:
Pros: file usage statistics can be persisted, which much improves user experience: it allows easily and quickly search necessary file on project with thousand source files. Also, it leads to a faster startup/project switch.
Cons: disk usage, and, probably a bit slower search, but I don't feel either.
The disk storage engine is preferable to me. What do you think about to switching to it?
PS. Also it is possible to use mixed approach (in theory, I don't know Lucene in details) : to tie in-memory and disk-storages : to use in-memory for search, and sync-to disk them on any changes. That also seems to be solving all problems.
In fact I removed the disk storage because even on a big project building the index is very fast, and the memory footprint is very low.
Being able to work in memory is also important when running with no settings. But I will find a solution to reintegrate the disk storage.
No, there is need to store indices on disk, the second time user opens jEdit and he can easily find frequently opened files . Could you, please, apply it on the trunk. I have other ideas, how to improve the search and it's appearance.
No, there is need to store indices on disk, the second time user opens jEdit and he can easily find frequently opened files . Could you, please, apply it on the trunk. I have other ideas, how to improve the search and it's appearance.
In fact it is already committed, I reintroduced the disk index, I'm currently using this version of SmartOpens to test, it seems it works well.