Re: BibTeX issues

[Roland Winkler <winkler@gnu.org>]

On Thu, Aug 29 2019, Joost Kremers wrote:
> On Wed, Aug 28 2019, Roland Winkler wrote:
>> 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.

I am currently playing with this.

> In order to display the title in a user-friendly manner, Ebib strips
> all TeX commands from a title, leaving only the obligatory argument.

A simple scheme of that kind can probably be added to
bibtex-autokey-transcriptions, though false-positives could be annoying.

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

`bibtex-clean-entry' is for testing whether an entry has the proper
format or not and for protesting if it believes there is a mistake.
But `bibtex-generate-autokey' is for, well, auto-generating a key,
assuming that the record is what the user wants / needs.  So I think
this behavior is intentional.

I noticed that the year/date alternative becomes a bit clumsy when it is
downgraded from "mandatory" to "crossref" in bibtex-biblatex-entry-alist
because bibtex-make-optional-field will give them both an ALT and OPT prefix

  ALTOPTyear =   {},
  ALTOPTdate =   {},

(which is of course in line with the usual behavior of bibtex-mode).
Also, this may break some code of bibtex-mode that assumes historically
that fields have either the ALT or OPT prefix.  Possibly, one can add a
user option not to insert any such prefix, which, I believe, is not
needed by `bibtex-clean-entry' either.  I need to check this more
carefully.