GNU bug report logs -
#51621
29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support
Previous Next
Full log
Message #35 received at 51621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 151 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.