Completion and caching
Michael Smith <[email protected]>
| Newsgroups | gmane.text.refdb.devel |
|---|---|
| Message-ID | <20031211224637.GA1796@theThirdPoliceman> |
Markus Hoenicka <[email protected]> writes: > Hi Michael, > > Michael Smith writes: > > Well, contents of those lists need not necessarily be in the menu itself > > in order to be made more easily accessible. It should be possible to > > come up with a mechanism for enabling users to do completion based on > > those. So, a user would select the Search > Author menu, then type the > > first letters of an author name -- "S" or whatever, then hit <tab> to > > complete against just the list of authors starting with S. > > > > Sounds good. > > Another issue: how do you deal with the fact that the database might > have changed between running two menu commands? Do you want to update > the author (or keyword or periodical) list each time the menu is > opened? That's what I have in mind to do, but I haven't done it yet. Certainly, it will have a performance difference. How much of a difference, I don't know. Mostly it will depend on how quickly refdbc returns the data. But also, once Emacs has the data, the code needs to take that and build an alist out of it (the completing-read needs an alist, not a list). I'm not sure if the time it takes Emacs to do that is significant or not. The way I'm doing it now to make the Select Database menu is to first build a list and then do this: (defun refdb-make-alist-from-list (list) "Make an alist from LIST by cons'ing elements with themselves." (mapcar (lambda (atom) (cons atom nil)) list) ) With a big list, I think it might be significantly faster to instead do it in one step. That is, just skip the step of building a list and instead just build alist with what refdbdc returns. Anyway, the more I consider this, I'm thinking maybe it makes a lot more sense, regardless of how the alists are built, to do this: - run queries at RefDB startup to build in-memory alists of authors, titles, etc. and use those (instead of re-querying the db each time) - have a 'Refresh Data Cache' menu item ('refdb-refresh-data-cache' command) that you can manually run to update the local cache How does that sound? --Mike
signature.asc
(application/pgp-signature, 155 B)
-----BEGIN PGP SIGNATURE----- iD8DBQE/2PPNsGCNMsnBsxkRAhySAKCHEQ+Osty0cC5SxaP/LiMQ6XS+MACeI/1m u4fbaBjn+h8VlW4koHxXeEM= =ZHq7 -----END PGP SIGNATURE-----