biblio.el icon indicating copy to clipboard operation
biblio.el copied to clipboard

Optional query argument for biblio-lookup

Open tmalsburg opened this issue 8 years ago • 9 comments

First off, thank you for this amazing package. I know I will use this a lot.

I'd also like to add an action for biblio-crossref-lookup in helm-bibtex where I already have a query string, so there is no need to prompt. I understand that I could call biblio--lookup-1 directly but I hesitate to do this because the double dash suggests that this function is not be part of the API. It would probably be cleaner to allow for an optional query argument for biblio-lookup and friends.

tmalsburg avatar Apr 03 '16 00:04 tmalsburg

Thanks, great suggestion!

cpitclaudel avatar Apr 03 '16 10:04 cpitclaudel

Both (biblio-crossref-lookup "abc") and (biblio-lookup #'biblio-crossref-backend "abc") should work now. Thanks for the feedback! (and congrats for the great helm-bibtex package!)

cpitclaudel avatar Apr 03 '16 10:04 cpitclaudel

Great, thank you!

tmalsburg avatar Apr 03 '16 19:04 tmalsburg

One question regarding the results list: I like how biblio presents search results but also noticed that this is very similar to how Helm presents results (in multi-line mode). Wouldn’t it make sense to use Helm to display the search results? This would probably simplify the code and would also allow the user to search within the results if there are too many. I realize that not everyone prefers Helm but in helm-bibtex, we were able to also offer Ivy support with only relatively few changes (see bibtex-completion.el and ivy-bibtex.el).

tmalsburg avatar Apr 03 '16 19:04 tmalsburg

+1 for using the helm interface. The current code displays ~7 lines of information for each result and plenty of blank space on the right. I would suggest adding everything on the same line (or maybe two lines) and removing the DOI url (I'm not sure why we would need to see that). This would make the results look more like a list, which may be easier to skim through. With helm we would also be able to narrow the results and get a few other conveniences (like helm-resume). BTW I looked through your code and it looks quite robust. Good work.

jagrg avatar Apr 04 '16 21:04 jagrg

I actually like the current layout and the DOI link. I use the link to check whether an entry is really the paper that I'm looking for or to read the abstract. Matter of taste I suppose.

tmalsburg avatar Apr 04 '16 22:04 tmalsburg

Reopening this :) I like the idea of using helm, though I don't want to make it a required dependency; I also like the idea of a list-like display, but not necessarily as the default. It should be easy enough to come up with a notion of frontends, and let users pick their favourite one.

cpitclaudel avatar Apr 04 '16 23:04 cpitclaudel

The extension doi-utils (see org-ref) opens the DOI url automatically and adds the bibtex key to the kill ring. Maybe this feature could be added to biblio as well. It basically automates part of the process of downloading PDFs. The user can also choose to create notes automatically after the bibtex entry is imported. But this would assume the user uses helm-bibtex or org-ref, which may not be the case.

Also, it would be nice if we were able to insert entries from any file (not just from the bib file). For example, if I'm drafting a paper and call biblio-lookup, I would like biblio to open my bib file and insert the selected entry on the bottom of that file, with an empty line between entries. This feature was recently added to doi-utils.

jagrg avatar Apr 05 '16 14:04 jagrg

Both of these should be pretty easy to implement, as extended actions or as extra entries in the selection mode keymap. Could you open separate feature requests for this? It makes it easier to track them :) I'll look at org-ref more closely; I'd like to minimize duplication across packages.

cpitclaudel avatar Apr 05 '16 15:04 cpitclaudel