Menu
▾
▴
#330 Improve File Content Search
It would be really cool if
1) the indexing of file content would be stored in a HD database cache instead of being generated each time BibDesk is restarted and file content search is invoked. The indexing cache should be updated when a new file is imported into the library. This would certainly accelerate the use of fulltext searches.
2) the search results would not only display the pdf file itself when double-clicked, but rather the bib entry, just as it is the case with the usual "Any Field" search result list. This would be both more logical and useful, in my opinion.
Logged In: YES
user_id=1162009
Originator: NO
1) has been discussed on the users list. There simply is no reliable way to tie a cached search index database to a bibtex file. Moreover the bibtex file can easily be edited with another program, which would break the cached index.
Logged In: YES
user_id=732757
Originator: NO
1) I agree with hofman; this is not possible. Possibly we could abuse EA to store it, but we'd be hitting size limits.
2) When you clear the search field, the items most probably associated with the file are selected. Due to limitations in Apple's search mechanism and the need to run it in a background thread, it's not possible to integrate it with the plain-text searching at this time.
Logged In: YES
user_id=1162009
Originator: NO
We may be able to use the cite key to get the item.
Logged In: YES
user_id=732757
Originator: NO
Right now we're mapping URL->Title via a hack, so I suppose it's technically possible to add a dictionary of info in the same way. It's a shame that SKIndexSetProperties is so slow. I think using the identifierURL would be better than citekey, though, since it's guaranteed unique and case-sensitive.
Logged In: YES
user_id=732757
Originator: NO
Another reason that files are displayed in the table is that all files associated with an item are searched; just showing the matching item wouldn't necessarily be sufficient to identify the matching file.