discard note and pdf fields of cross-referenced entries #214
Conversation
|
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? |
|
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 |
|
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. |
Add optional argument FIND-CROSSREF to `bibtex-completion-find-pdf` that appends PDFs from cross-referenced entries. This argument is set to t in action functions (no need to do this when building the bibliography because the "=has-pdf=" field is inherited from the cross-referenced entry). Also `bibtex-completion-find-pdf` now calls `bibtex-completion-get-entry1` directly if needed and makes sure to pass an entry to `bibtex-completion-find-pdf-in-field` or a key to `bibtex-completion-find-pdf-in-library` (which allowed small simplifications of these latter two functions). This avoids situations where `bibtex-completion-get-entry1` would be called twice for the same key.
|
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 |
|
Sorry, I lost track of this. I wish I had more time for this project. |
|
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. |
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.