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

[Leo Stein <leo.stein@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Hi,

I wanted to raise a bug report but found this earlier one from 3 years ago
that was almost the same as my own. I was confused about why BibTeX-mode
was happily fontifying a doi=... field within a @software entry, and
attaching a button to it, but I could not follow the URL — because
BibTeX-mode thinks @software is not an allowed type within the "BibTeX"
"dialect". So, bibtex-parse-entry returns nil. This is because the regex
bibtex-entry-head is built from all "valid" entry types of the "dialect".

However, there is no reason @software, or any other type of entry, should
be an "invalid" entry in a bibtex file. It's the purview of whatever bibtex
style (defined in a .bst file) to determine what to do with different
entries. Some bst's default to passing things along to the @misc entry
type. But, I count 7 different bst's in the 2024 TeXLive tree that define a
@software type, and I'm sure there are many more custom types (e.g. the TeX
User's Group's tugboat.bst defines an entry type for @ctan , i.e. to cite
an entry on the Comprehensive TeX Archive Network).

I'm starting to think that the "dialect" design within bibtex.el was
confused about bibtex vs. biblatex (this is pretty confusing, as we can see
here: https://tex.stackexchange.com/q/25701/34063). However, I'm not sure
what is the correct solution. At the very least, bibtex.el should be more
permissive about what entry types get parsed by bibtex-parse-entry.

Best
Leo

[-- Attachment #2: Type: text/html, Size: 1767 bytes --]