Dear Roland,

That web site looks quite good, thanks for sending the link. This spurred me on to see what bibtex's own documentation looks like. CTAN contains the bibtex.web source file in biblio/bibtex/base. That is ultimately the specification of how bibtex parses, and also generates its documentation, which is available in e.g. TeXLive at the path texmf-dist/doc/generic/knuth-pdf/bibtex/bibtex.pdf .

There we can see that when parsing an entry, if the entry type is found in a hash that's populated from a bst file, the bool type_exists is set to true. Otherwise, type_exists is set to false. The only thing that happens when type_exists is false is generating a warning message (see Sec. 273). It is *not an error* to use a type that is not defined in a bst file (which, again, I emphasize, BibTeX-mode has no way of knowing).

How about this proposal? Can BibTeX-mode have a (customizable) boolean variable, something like bibtex-parse-permissively? If this flag is nil, BibTeX-mode would operate as it does right now. If this flag is t (or maybe just non-nil?), then bibtex-parse-entry would parse entries just according to the regexps on the nice web site you sent — that is, ignoring the value of bibtex-entry-alist.

Best,
Leo

On Sun, Jan 12, 2025 at 11:56 PM Roland Winkler <winkler@gnu.org> wrote:
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.