> I created CSL, and have helped develop the data schema.
Well, that's what I call a reliable source :) I suppose this is as
good a time as any to say thanks for all that!
> it's likely we'll change the date property to prefer an
> EDTF string
Will that be stored in the `raw` or `literal` field? In that case, the
current implementation should work with (not too wild) EDTF strings.
If not, code will have to be added to extract the value from the
appropriate field.
> I'd prefer an explicit cond here. format "%s" may silently
> work on malformed json files and will mask issues with
> bibliography from the user.
Sure, good idea :)
> Would you mind creating a patch and possibly supplying a test
> that will make sure that the example file and similar are correctly
> parsed?
I'm attaching a patch (just the patch for now, no commit message), let
me know what you think, in particular the error message. What would be
an acceptable way to wrap the format string?
As for tests -- if `oc-basic.el` already had some, I'd try to see if I
can come up with something by analogy. But as it stands, I know too
little about Elisp, nothing about Elisp testing, and have too little
spare time, sorry :(
Best,
David
diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index a937f75..f10b95b 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -189,7 +189,14 @@ Return a hash table with citation references as keys and fields alist as values.
(cons 'year
(cond
((consp date)
- (caar date))
+ (let ((year (caar date)))
+ (cond
+ ((numberp year) (number-to-string year))
+ ((stringp year) year)
+ (t
+ (error
+ "First element of CSL-JSON date-parts should be a number or string, got %s: %S"
+ (type-of year) year)))))
((stringp date)
(replace-regexp-in-string
(rx
