month = jan etc not parsed correctly

[rcoreilly]

Apparently the official BibTex spec says that months should be three-letter abbreviations like jan, feb etc, not in {}, and then when you run BibTex it localizes these in your local language. So they are pre-defined @Strings. The parser currently barfs on these. I could try to fix it or if you could do it quickly then that might be easier :)

[rcoreilly]

ps. also it might be friendlier to just log.Printf such errors instead of doing log.Fatalf -- I'm including this in an editor to lookup \cite keys and if there are a few errant entries I don't want my whole app to immediately terminate.

[rcoreilly]

Other than the month issue, and a few errant items in my .bib file with random @ symbols and ? in the cite key, this package seems to quickly digest my rather large 28k entry bib file (generated from betterbibtex and Zotero) -- thanks for making this available!

[rcoreilly]

also for extra robustness, this prevents a crash when you comment out the fatal for undefined strings:

func (v *BibVar) String() string {
	if v == nil {
		return ""
	}
	return v.Value.String()
}

[nickng]

Apparently the official BibTex spec says that months should be three-letter abbreviations like jan, feb etc, not in {}, and then when you run BibTex it localizes these in your local language. So they are pre-defined @Strings. The parser currently barfs on these. I could try to fix it or if you could do it quickly then that might be easier :)

@rcoreilly Yeah sounds good -- I'll add them, could you point me to the specs that define these? Just wanted to see if they clarify subtle details like mixed/upper case for these keywords.

I'll keep the parser rejecting bibtex files that are using invalid syntax. I'll be holding off changing the behaviour for undefined strings to return empty (other than the month abbreviations). It'll be easy to miss subtle problems like these in bibtex files (very much the reason why I'm avoiding the standard bibtex program which is IMO too lenient on the syntax).