bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leo Stein
Subject: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support
Date: Sat, 30 Nov 2024 22:33:11 -0600

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]