Add "=has-link=" to bibtex-completion search string

[bdarcus]

EDIT: based on discussion below, I've narrowed the request, and updated title and this description accordingly.

---

I propose to add "=has-link" to the candidates, to indicate the presence of DOI or URL, and therefore those candidates where the "open" functions will return a result.

Could also add has:note etc to the candidate search strings instead of the symbols, which aren't ideal for search.

[tmalsburg]

I was wondering how to search for presence of notes (or also PDFs or links) using the bibtex-completion functions.

Bibtex-completion itself doesn't implement any searching as this is left to the completion frameworks, currently helm and ivy. In both helm- and ivy-bitbex the only way to search for entries with PDFs and notes is to enter the symbols that are used to indicate their presence, i.e. bibtex-completion-pdf-symbol and bibtex-completion-notes-symbol.
For PDFs, an alternative is to include the file field in bibtex-completion-additional-search-fields and then you can search for .pdf. A bit of a hack, though. There's no straightforward way to search for entries that have content in the URL field ... although you could add that to bibtex-completion-additional-search-fields as well and then search for http.

Could we just allow some convention (like "has:pdf" sort of thing) to search within the standard commands?

In principle we could do that, but I'm not sure it's needed. In 7 years I never needed to search for entries that have, for instance, an URL attached to them. The implementation would be easy. We'd just have to add has:XYZ for all existing fields XYZ to the string which is in the first cons cell of each entry. However, there's a price to pay for that. Construction of these strings is more expensive and searching, too. Since speed is already an issue we'd need to carefully consider whether the benefits out-weight the costs. I tend to be skeptical because we'd get the slow-down on every search but the benefit only in rare use cases.

Maybe could be generalized for search by field, like d:201 t:foo has:pdf,

I don't understand. What are d:201* and t:foo* supposed to match?

either adding a conventional prefix to field data incorporated into the search string generated by bibtex-completion-candidates, or by allowing users to configure this as they do for bibtex-completion-format-entry?

If not, should not the ivy and helm commands for this have a bibtex-completion function they wrap?

[bdarcus]

I don't understand. What are d:201 and t:foo supposed to match?

Date and title respectively.

The asterisks maybe just confuse the issue.

However, there's a price to pay for that. Construction of these strings is more expensive and searching, too.

OIC. I can see that.

Would having something different than the "has note" symbol (which isn't helpful for search) in that string be a problem from that perspective?

[tmalsburg]

d:201 and t:foo

This would be useful indeed, but since the actual searching is provided by helm and ivy, we can't easily change the search syntax. However, the search syntax (regular expressions) is quite powerful already. For instance if you want papers from the period 2002 to 2007 you can enter 200[2-7]. It will also match entries that have any of those numbers in other fields but that's pretty rare and the occasional false positive doesn't bother me.

Would having something different than the "has note" symbol (which isn't helpful for search) in that string be a problem from that perspective?

Replacing the "has note" and "has pdf" symbols by strings is cheap and useful enough to justify the cost. I have a vague memory that this topic was discussed in a older issue; we should check before writing any code.

[bdarcus]

I have a vague memory that this topic was discussed in a older issue; we should check before writing any code.

I did do a (somewhat quick) search, but couldn't find anything.

[bdarcus]

Replacing the "has note" and "has pdf" symbols by strings is cheap and useful enough to justify the cost. I have a vague memory that this topic was discussed in a older issue; we should check before writing any code.

Was it #318?

FWIW, this is how I implemented it in my code, but could still use a "=has-link=" field.

[tmalsburg]

I've just added support for =has-pdf= and =has-note= which are both useful and reasonably cheap (9870333cdd4a54b309e2709af647cda6f4070a42). As I said earlier, I'd rather not add support for checking the presence of all kinds of other fields because it would likely slow down parsing too much.

[bdarcus]

Thanks.

FWIW, in the linked PR (#366), I ended up only adding the =has-link= cons; didn't actually touch the candidate string.

And the justification for including it is that it relates to the relevant "open" function. E.g. it's annoying to run that action/command on an item that will return nil.

[tmalsburg]

didn't actually touch the candidate string.

Ah right. Should have noticed that.

And the justification for including it is that it relates to the relevant "open" function. E.g. it's annoying to run that action/command on an item that will return nil.

Well you do get a message, not just nothing. But I see the point. The root issue, though, is that the URL and DOI are missing. Would be cool to have an elisp command that automatically queries some online data base (e.g. crossref) and adds missing DOIs. I'm not using bibliography managers like Zotero, Mendeley et al. but perhaps one of them already has that feature?

[bdarcus]

The root issue, though, is that the URL and DOI are missing.

It's worse than that; they don't exist.

Think historical documents.

[tmalsburg]

Got it. And, yes, has-link is really useful then.