helm-bibtex
helm-bibtex copied to clipboard
BibLaTeX Compatibility Issues
We added a fix for the date field which biblatex uses instead of year, but the code for this is littered all over the place.
My own workaround looks something like this:
(defun annobib-apa-format-reference (key)
"Adapted from `bibtex-completion-apa-format-reference`.
Returns a plain text reference in APA format for the
publication specified by KEY."
(let*
((entry (bibtex-completion-get-entry key))
(ref (pcase (downcase (bibtex-completion-get-value "=type=" entry)))))
;; APA Citation Format
("article"
(s-format
"${author} (${date}). ${title}. ${journaltitle}, ${volume}(${number}), ${pages}.${doi}"
'bibtex-completion-apa-get-value entry))
(_
(s-format
"${author} (${year}). ${title}."
'bibtex-completion-apa-get-value entry))
(setq ref (replace-regexp-in-string "\\([.?!]\\)\\." "\\1" ref)); Avoid sequences of punctuation marks.
(setq ref (replace-regexp-in-string "[{}]" "" ref)) ;; Remove braces.
))
Note that all year
field indicators must also be changed to date
, presently with no option to choose the year part from the date-string (as far as I know, but I might be wrong).
Another issue is this: for the thesis
reference type, BibTeX
uses phdthesis
and mastersthesis
to differentiate between the two, while BibLaTeX
just makes do with thesis
with phd and ma indicated in the type
field.
Can there be a separate biblatex-completion
for biblatex
users? Or some other way to make citing with biblatex
more user-friendly?
Originally posted by @sati-bodhi in https://github.com/tmalsburg/helm-bibtex/issues/217#issuecomment-714974417
This is a follow-up of the issue referenced above. I would like to know how the issue of BibLaTeX
compatibility with BibTeX
fields and reference types stands with helm-bibtex
as of now, and whether, by any chance, there is a possibility of having a set of completion code that is completely compatible with BibLaTeX
.
Outstanding issues include date
vs year
fields, journaltitle
vs journal
and reference type thesis
with a certain type
as opposed phdthesis
and mastersthesis
etc.
I am also working to make the completion code able to detect, and thereafter apply a different string format to other language references, such as Chinese. (But that would be another issue.)
I implicitly raised this issue a few years back with #192, as I use biblatex data.
What's the status ATM?
No updates. I use BibLaTeX as well but with year/month/day fields and it's working without problems. We could create an ad-hoc fix, but if we want to do something about this (I never see data fields in the wild), I think we should think about a more principled approach since there are other relevant differences between BibTeX dialects as well. One complication is that many people have messy bibliographies that mix and mash various dialects. Not easy.
Date seems a particularly important one perhaps easy to support without problem?
Edit: already supported :-)
Biblatex recently adopted the EDTF ISO date representation, which gives wider latitude to handle complex dates.
But the nice thing about that standard is, depending on what levels biblatex actually supports (I need to look again at the details) simply pulling the first four characters of those strings is still helpful for display results.
Edit: already supported :-)
Oh, right. I forgot that we had already fixed that in 2017. :)
What else needs to be done specifically to address this issue, e.g. the specific issue of phdthesis/masterthesis vs. thesis? The only reference to phdthesis
is in bibtex-completion-apa-format-reference
where it would be trivial to add another case for thesis
. I don't see how/why this requires more changes than that.
@sati-bodhi perhaps you could spell this out a bit more? At this point I find the description of the issue a bit too vague and perhaps also too broad to determine what would need to be done before it can be closed. Thanks.
I ran across one issue:
Library display and such will use date
, but reference formatting will not.
Library display and such will use date, but reference formatting will not.
Good point. That's something that we should fix. (The current issue is more general in scope I think.)