Re: BibTeX issues

[Joost Kremers <joostkremers@fastmail.fm>]

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
>> missing
>
> 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