From: Joost Kremers <joostkremers@fastmail.fm>
To: emacs-devel@gnu.org
Subject: Re: BibTeX issues
Date: Thu, 29 Aug 2019 09:49:51 +0200 [thread overview]
Message-ID: <87o908tnq8.fsf@fastmail.fm> (raw)
In-Reply-To: <87ftllji9u.fsf@gnu.org>
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
next prev parent reply other threads:[~2019-08-29 7:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 8:40 BibTeX issues Joost Kremers
2019-08-28 17:45 ` Roland Winkler
2019-08-28 18:45 ` Eli Zaretskii
2019-08-29 3:26 ` strip accents and sorting [was: BibTeX issues] Roland Winkler
2019-08-29 6:15 ` martin rudalics
2019-08-30 16:27 ` Roland Winkler
2019-08-30 17:51 ` Eli Zaretskii
2019-08-30 18:38 ` Eli Zaretskii
2019-08-30 19:09 ` Roland Winkler
2019-08-30 19:19 ` Eli Zaretskii
2019-08-30 19:49 ` Roland Winkler
2019-08-31 6:45 ` Eli Zaretskii
2019-08-29 7:10 ` Eli Zaretskii
2019-08-30 16:29 ` Roland Winkler
2019-08-29 7:49 ` Joost Kremers [this message]
2019-08-30 19:18 ` BibTeX issues Roland Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o908tnq8.fsf@fastmail.fm \
--to=joostkremers@fastmail.fm \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.