BibTeX types/tags are case-insensitive, etc

[Omikhleia]

Closes #1409

Fixes several issues:

• BibTeX types (@article, @book, etc. and @comment) must be case-insensitive
• BibTeX tags (labels, i.e. author, editor, year, etc.) must be case-insensitive
• Other fixes...
  • Some attempts at concatenating tables (options vs. options.key) in error/warning messages
  • A missing error code (UNKNOWN_TYPE)
  • Some minor fixes (e.g. "type" entry in bibtex files need some renaming to avoid overriding the type() function) and minor error check and reporting improvements.

Additionally:

• Update article and book references to Chicago Citation Style 17th Edition
• Add fallbacks for other usual BibTeX types (thesis, booklet etc.). It's somewhat hard to map those to the Chicago style in a generic way, so it doesn't claim to be perfect, but at least the output should be reasonable.

This is slightly better than what we had, anyway.

[Omikhleia]

I am removing my "WIP" from the PR status - As far as I am concerned, I think this is minimally sufficient to address the original issue and get back to a "working" state on this experimental package.

Needed steps to move forward out of "draft" status:

• Review, obviously...
• I added a test (tests/bibtex.sil) but didn't push the expected result: For some reason, my SILE 0.13.2 docker uses Gentium v7 while our tests currently expect Gentium v5. I would appreciate if someone could generate the expectations and check them.

Could be an occasion to check my mappings are indeed decent enough, I have seldom used BibTeX ^^

[alerque]

Thanks for working on this. I'm considering cutting a v0.13.3 release from a patch branch because my work on v0.14.0 is quite extensive and testing it might take a little bit yet. Should this go in that?

[alerque]

For some reason, my SILE 0.13.2 docker uses Gentium v7 while our tests currently expect Gentium v5.

The Docker images are built with Arch Linux, which currently packages Gentium 6.101. Since that was built before the v0.13.2 release I would expect that to be in the Docker image. But at the end of the day it shouldn't matter what is built into Docker because our test system doesn't use any system fonts.

The test system uses a hard coded list of fonts with direct download rules to get the exact versions we want, then special invocations that exclude fontconfig finding system fonts and only using the test suite list. When you update expectations you should be using the same FONTCONFIG setup as the tests use, which can be done with make update_expecteds, even granularly with make update_expecteds TESTSRCS=tests/specifictest.sil or if you know the name of the output you want, just make tests/specifictest.expected.

I would appreciate if someone could generate the expectations and check them.

Sure, glad to. Also glad to see this package getting some tests, they have been sorely lacking to date!

[Omikhleia]

I'm considering cutting a v0.13.3 release from a patch branch because my work on v0.14.0 is quite extensive and testing it might take a little bit yet. Should this go in that?

I'm a bit lost in the release lifecycle, honestly (and the quick pace of some updates). Would you ask, I'd say:

• Fit in a 0.13.x
  • everything we have "ready" as non-breaking PRs. Those have no reason to wait for a 0.14.
  • a few things that 0.13 introduced and would need to be fixed/improved (here in that case, I'd say for instance e.g. Review the fluent (i18n) implementation #1477 and Localization for as many languages as possible #1474 = honor the 0.13 "Charter" claims without too many leftovers)
• Fit in a 0.14.0
  • everything we have as breaking PRs or PRs still in progress / needing changes.
  • that would include some things marked as 0.14.x currently, but there's far too many things in that milestone (incl. things which haven't been started at all yet, that were moved from milestones to milestones, etc. We are perhaps running too many marathons, there!).
  • That 0.14 could occur in September or even later (= 3 months or so after 0.13.0) so as to leave some time for testing/reviews and possibly fit more things (e.g. when Add inline-escaping in SIL-language #1347 makes it to master, maybe we can add some of the easily-reachable converters e.g. such as dot -- further to my comment in Pikchr integration #1434 I haved added that to my own repo and markdown converter -- and prepare the way it could be generalized)