Subject: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support

From: Roland Winkler <[email-masked]>
Date: Sun, 12 Jan 2025 23:56:00 -0600

On Mon, Jan 06 2025, Leo Stein wrote:
> I'm glad you are adding more customization. 1. Why is the standard
> value of bibtex-BibTeX-aux-entry-alist given as '(("Conference"
> "Article in Conference Proceedings" "InProceedings")) ? 2. I still
> don't understand the point of making a distinction between
> "dialects". As I've tried to emphasize before, which fields are
> accepted is under the purview of the bst (for bibtex) or bbx/cbx/lbx
> file (for biber+biblatex) that the user will eventually use. That
> can't be inferred from the contents of a .bib file; in fact, a .bib
> file could be used in multiple different projects with different
> bst/bbx/cbx/lbx files, all of which allow for different fields. I
> still maintain that the best approach is to be permissive about
> *parsing* entries in bibtex-parse-entry. That is a different question
> from the contents of templates provided by C-c C-e [KEY], for which of
> course the mode must know about the structure of each given entry.

I was looking at this again.  In theory, this is all (more or less)
straightforward.  In real life, BibTeX is tricky because

  "there is no formal specification of the language.  This means that
  users exploring the arcane corners of the language are largely on
  their own, and programmers implementing their own parsers are
  completely on their own---except for observing the behaviour of the
  original implementation."

This quote is taken from the most accurate documentation of the
BibTeX "language" I am aware of,

https://metacpan.org/dist/Text-BibTeX/view/btparse/doc/bt_language.pod

This documentation was written by the author of btparse, which is the
BibTeX parser used by biber / biblatex.  So these problems are the same
under conventional BibTeX and biblatex.

Emacs bibtex-mode needs to come up with its own parser, for which it
follows a conservative approach that explicitly defines valid entries.
Agreed, this approach is not perfect.  But trying to do better is an
arduous undertaking full of hidden pitfalls.