[-- Attachment #1: Type: text/plain, Size: 132 bytes --] This is a tiny change that just checks for a 'date' field if 'year' is nil, and if present, grabs the first four characters. Bruce [-- Attachment #2: 0001-oc-basic-Support-biblatex-date-field.patch --] [-- Type: text/x-patch, Size: 1729 bytes --] From feee2ca6d54d3495050de334c258438950494372 Mon Sep 17 00:00:00 2001 From: Bruce D'Arcus <bdarcus@gmail.com> Date: Fri, 29 Oct 2021 08:17:43 -0400 Subject: [PATCH] oc-basic: Support biblatex date field * lisp/oc-basic.el (org-cite-basic--print-bibliography, org-cite-basic--get-year): Check 'date' field if 'year' nil. --- lisp/oc-basic.el | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el index 1a01ea408..1c5634341 100644 --- a/lisp/oc-basic.el +++ b/lisp/oc-basic.el @@ -345,7 +345,9 @@ patterns." ;; the cite key, as a string, and SUFFIX is the generated suffix ;; string, or the empty string. (let* ((author (org-cite-basic--get-field 'author entry-or-key info 'raw)) - (year (org-cite-basic--get-field 'year entry-or-key info 'raw)) + (year + (or (org-cite-basic--get-field 'year entry-or-key info 'raw) + (substring (org-cite-basic--get-field 'date entry-or-key info 'raw) 0 4))) (cache-key (cons author year)) (key (pcase entry-or-key @@ -371,7 +373,9 @@ ENTRY is an alist, as returned by `org-cite-basic--get-entry'. Optional argument INFO is the export state, as a property list." (let ((author (org-cite-basic--get-field 'author entry info)) (title (org-cite-basic--get-field 'title entry info)) - (year (org-cite-basic--get-field 'year entry info)) + (year + (or (org-cite-basic--get-field 'year entry info) + (substring (org-cite-basic--get-field 'date entry info) 0 4))) (from (or (org-cite-basic--get-field 'publisher entry info) (org-cite-basic--get-field 'journal entry info) -- 2.33.1
Hello,
"Bruce D'Arcus" <bdarcus@gmail.com> writes:
> This is a tiny change that just checks for a 'date' field if 'year' is
> nil, and if present, grabs the first four characters.
The date field may also be nil, leading to an error.
Is there a guarantee that the date field starts with the year?
Regards,
--
Nicolas Goaziou
On Tue, Nov 2, 2021 at 1:44 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > > Hello, > > "Bruce D'Arcus" <bdarcus@gmail.com> writes: > > > This is a tiny change that just checks for a 'date' field if 'year' is > > nil, and if present, grabs the first four characters. > > The date field may also be nil, leading to an error. Can you please fix that, if the patchis otherwise fine? > Is there a guarantee that the date field starts with the year? Not 100% guarantee, but should be close. The biblatex manual (section 2.3.8 Date and Time Specifications), says the following: "Date fields such as the default data model dates date, origdate, eventdate, and urldate adhere to iso8601-2 Extended Format specification level 1." This is an extension to standard 8601 dates, previously known as EDTF (extended date-time format). So for the vast majority of cases, yes; the value would be standard 8601 dates. The exceptions should be very rare open-ended ranged dates; from table 3. ../1997 /1997 I do not, however, have a good knowledge of what people do in the wild. It just seems like such a critical data field should be supported. Bruce PS - FSF confirmed my copyright assignment today.
Hello, "Bruce D'Arcus" <bdarcus@gmail.com> writes: > Can you please fix that, if the patchis otherwise fine? OK. > The biblatex manual (section 2.3.8 Date and Time Specifications), says > the following: > > "Date fields such as the default data model dates date, origdate, > eventdate, and urldate adhere to iso8601-2 Extended Format > specification level 1." > > This is an extension to standard 8601 dates, previously known as EDTF > (extended date-time format). > > So for the vast majority of cases, yes; the value would be standard 8601 dates. > > The exceptions should be very rare open-ended ranged dates; from table 3. > > ../1997 > /1997 > > I do not, however, have a good knowledge of what people do in the > wild. It just seems like such a critical data field should be > supported. I pushed a change along these lines in bugfix branch. Please let me know if it works for you. Thank you. Regards, -- Nicolas Goaziou
On Wed, Nov 3, 2021 at 11:16 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > I pushed a change along these lines in bugfix branch. Thank you! > Please let me know if it works for you. This returns the correct result. (org-cite-basic--get-year "kohn2005" nil) How do I get that in the basic activate processor tooltip? That was my main reason to suggest it. Bruce
Hello,
"Bruce D'Arcus" <bdarcus@gmail.com> writes:
> This returns the correct result.
>
> (org-cite-basic--get-year "kohn2005" nil)
>
> How do I get that in the basic activate processor tooltip?
`org-cite-basic-activate' calls `org-cite-basic--print-entry', which in
turn calls `org-cite-basic--get-year'.
IOW, the tooltip should already use the date if the year is unavailable.
Isn't is the case? Do you have an ECM?
Regards,
--
Nicolas Goaziou