[Top][All Lists]

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

Re: BibTeX issues

From: Joost Kremers
Subject: Re: BibTeX issues
Date: Thu, 29 Aug 2019 09:49:51 +0200
User-agent: mu4e 1.3.4; emacs 26.2

Hi Roland,

First, thanks for your answer. Perhaps I should have given some background in my previous mail: I maintain a package called Ebib, which implements a BibTeX database manager for Ebib. It uses some of the functionality of bibtex.el (specifically, the entry type definitions and the autokey machinery), which is how I (or rather, a user of Ebib) ran into these issues.

On Wed, Aug 28 2019, Roland Winkler wrote:
On Tue, Aug 27 2019, Joost Kremers wrote:
First, the date field does not seem to be recognised at all. In
biblatex, the date field replaces the year field, in that it is
considered the preferred way of providing the year of publication
for an entry.

How about allowing the possibility that the first arg FIELD of
bibtex-autokey-get-field can also be a list of fields so that the elements can be treated as alternatives? Assuming that a bib(la)tex entry has either a year or a date field, then bibtex-autokey-get-year
could use one or the other.

Yes, that would be great. Biblatex requires that either date or year be present, so it's a safe assumption that one of them will be. Biblatex favours date over year, so I'd suggest date be checked first.

One thing to keep in mind is that the date field can contain a full date + time, not just a year, and even date ranges, so in order to produce a year part for the autokey, the date field needs to be parsed. This shouldn't be too difficult, though, since the format of the date field is clearly defined. (The biblatex doc has all the details.)

Second, it isn't clear to me how `bibtex-generate-autokey` handles
macros in titles, specifically \emph.

I never had such a problem. Details probably depend on your use cases. A generic parser for LaTeX code that can drop such things is probably not all trivial. (But maybe something of that kind exists alread (at
some level) for auctex or org mode or some other package?)

I don't know about AUCTeX or Org mode (perhaps org-ref has something), but I do something like this in Ebib: In order to display the title in a user-friendly manner, Ebib strips all TeX commands from a title, leaving only the obligatory argument. (It also does some fontification, BTW.) It works well enough for my use-case, but it'll break in more complicated cases; e.g., it doesn't take into account multiple obligatory arguments, and it doesn't handle extensions to the default LaTeX syntax that some packages (most notably biblatex...) implement, such as arguments delimited with parentheses or pointy brackets, and optional commands in between obligatory ones.

Last, but certainly not least, doing `bibtex-clean-entry` in an
entry with a valid `crossref' field doesn't seem to work. Instead, I
get the following error:

bibtex-format-entry: Alternative mandatory field ‘(date year)’ is

I am not a biblatex expert. Since BibTeX mode picked up biblatex support in 2013, it has treated the alternative fields date and year as mandatory, see the default of bibtex-biblatex-entry-alist. Do you say
that these fields should be treated as crossref fields instead?

Yes. In fact, both the BibTeX and the biblatex documentation state that *all* fields are inherited if they are present in the parent and not in the child. (With biblatex, this is a customisable option, but it's on by default.) Obviously, for fields such as author and title, inheriting them doesn't make much sense, but for year and date it usually does. BTW, `bibtex-generate-autokey` does in fact treat the year field as inheritable. It's `bibtex-clean-entry` that protests when the year field is missing.

Joost Kremers
Life has its moments

reply via email to

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