discard note and pdf fields of cross-referenced entries

[ericdanan]

Currently if an entry has no note / pdf file but cross-references an entry that has one, then the former entry will incorrectly be marked as having a note / pdf file in the candidates list. This is because the note / pdf field is inherited when resolving cross-references. So this PR simply makes sure to discard these fields at that stage.

[tmalsburg]

I agree regarding the notes but I'm not sure about the inherited PDFs. One use case for crossrefs (im my case the only one) is conference proceedings where you have one PDF for the conference and you crossref these proceedings from the individual contributions to that conference.

What are your use cases for crossrefs?

Perhaps inheritance of PDFs should be decided depending on the entry type: Inherit PDFs from proceedings to inproceedings but not in some other cases?

[ericdanan]

My use cases are mainly inproceedings and inbook. For the latter, it could be that each chapter has a pdf or there is a single one for the whole book, so I'm not sure we can systematically infer the correct behavior from the entry type.

I agree it can make sense to inherit the pdf file from the proceedings / book, but the problem then is that bibtex-completion-open-pdf fails for an individual contribution / chapter, because it doesn't try with the crossref key. So perhaps a better solution would be to make that function try with the crossref key if there is one? In which case, should we do that unconditionally or only if the primary key yielded no pdf? And we should also take care of pdfs found in field, currently bibtex-completion-find-pdf-in-field doesn't fetch the crossref info.

[tmalsburg]

I tend to favor a solution where we inherit PDFs unconditionally. So if there is a PDF for the entry and one for the crossreffed entry, we'd collect both. This deviates from how inherited values are handled for other fields (where the local value strictly overrides the inherited value) but the PDF value is slightly non-standard also in some other respects and I think it might be useful in some situations to have all PDFs.

Having said that, I understand if you don't want to work on this and would be happy to merge the PR as is.

[ericdanan]

Sure, done (I started from scratch and force-pushed).

I've put some comments in the first commit which is the most substantial one.

The last two commits are not completely related to the present issue, but I noticed that in all places where bibtex-completion-get-entry (or bibtex-completion-get-entry1) is used, it seems unnecessary to find pdf and notes files. So I added an optional argument to not find notes and made sure neither pdf nor notes are found in these places. I could instead have removed the optional argument to not find pdf and make these two functions systematically not find for pdf and notes, let me know if you want to go this way, I was reluctant to do it without you approving first.

[tmalsburg]

Sorry, I lost track of this. I wish I had more time for this project.

[ericdanan]

Sorry, I wanted to clean up old branches and deleted that one by mistake. So just restored it and reopening the PR, but feel free to close again.