Abdelrazak Younes wrote: > Richard Heck wrote: >> So now I type an >> "a". That narrows it down to everything that contains "sa". Again, >> little progress. Now I type "m". That will weed out a few things, but >> possibly not very many, especially because I have a lot of annote, >> abstract, and review fields in the database. (Note here that the current >> BibTeX parser loads all fields and searches all fields.) So there are >> going to be three pretty much full DB searches, and the fourth one will >> likely be quite large as well. Of course, I've chosen a bad case. If I'd >> type "fre", I'd have made more progress. But still it is slow. > > I see. I just want to say that I tested this extensively at the time I > implemented it (that was before the new parser) and the speed was OK > even with a _lot_ of entries. My test case was to load all Bibtex > files that come with Miktex. > > If the speed is now a problem, I guess a check box "Find as you type" > which default to yes is necessary. Yes. I'll do this when I do some other things with that dialog, after 1.5.0. As I said in an earlier message, now that we have parsed BibTeX data, it's trivial to implement the ability to search a particular field, say, title. The only question is what the UI should be: title=whatever, as in JabRef, or two text fields, or a dropbox (which could get its data from the parser), or what.
Richard -- ================================================================== Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ ================================================================== Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
