From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.devel Subject: Re: BibTeX issues Date: Thu, 29 Aug 2019 09:49:51 +0200 Message-ID: <87o908tnq8.fsf@fastmail.fm> References: <87mufv2e9s.fsf@uni-bielefeld.de> <87ftllji9u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="226256"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.3.4; emacs 26.2 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 29 09:51:56 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i3FDn-000wiG-I8 for ged-emacs-devel@m.gmane.org; Thu, 29 Aug 2019 09:51:55 +0200 Original-Received: from localhost ([::1]:46592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3FDm-0005Nh-14 for ged-emacs-devel@m.gmane.org; Thu, 29 Aug 2019 03:51:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49904) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3FBx-0005Kg-Pe for emacs-devel@gnu.org; Thu, 29 Aug 2019 03:50:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i3FBt-0003pu-Ed for emacs-devel@gnu.org; Thu, 29 Aug 2019 03:50:01 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:43637) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i3FBs-0003nq-Hu for emacs-devel@gnu.org; Thu, 29 Aug 2019 03:49:56 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 65E8B2102F for ; Thu, 29 Aug 2019 03:49:54 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 29 Aug 2019 03:49:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= references:from:to:subject:in-reply-to:date:message-id :mime-version:content-type:content-transfer-encoding; s=fm1; bh= 1ayfSV6szEIZ6EUkSqHQ2nX58Q3vVHZ9Eq1FJO1+ZUI=; b=LIx/XLs5zJH6wHYx frZptVMg2cyyzsRDxfwjAJUrmcnaqpMrTaYoBswuvSrMJcNHhQXeHguzR3tEQxGW tREduF+Ri8DRO4Jbl+r2mrz2O35R4qRIhccNXuZ80NnA5DmPwD5Y5+lbGPQx5R35 n9KQ9zeGwh5re1VxVSSHdEuy4LvNWJGz10jP5m6AVESXUuzSPuzq2zd0yP61O+Sn FGvlbP+/v4qZNB1eJHSxAyNMEces9TQHQLv9pTI5J0fkatWxkfAuPY7UkA4Rm2AV L4AK9t5id3+onwp+bx40dWlGr9ObZthN9KGwKc9vbQ4QjZquS6I46PIZYFKm+lxK xI9/5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=1ayfSV6szEIZ6EUkSqHQ2nX58Q3vVHZ9Eq1FJO1+Z UI=; b=D2aQSs6FwjXRM0ymD/7E1iGv45p3fuIVE0LboqGo56ND6SIg9JkIJL0xF I83LJwnE5ywjgKbWA1K0vdNXlA9+SzkLHcj9jVpBgcVYdUadXsMbY05gI5NRIYnH hQEAQ8j0u423Wc4FJ0jPcwMA48eGAUy/m/CkqRdMNzGoJ6T380idf9ds8Oh6TO1K 7nYGs5koI4LBwIJGBjVvjFP2sRTaHm5yNqR1XYifK4Ei/++knefXG9boLwf1kqgB 3J+47eiDewm3oYMT3pLifpfpvEIBvmJAmQZJ/9em/ilomkYSKBnWZ4K3yg1s35y+ Pc/SbV9ruBavPwVIJEg66Uzau6h2Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeiuddguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfhgfhffvufgjfffkgggtgfesth hqredttderjeenucfhrhhomheplfhoohhsthcumfhrvghmvghrshcuoehjohhoshhtkhhr vghmvghrshesfhgrshhtmhgrihhlrdhfmheqnecukfhppeduvdelrdejtddruddthedrud eggeenucfrrghrrghmpehmrghilhhfrhhomhepjhhoohhsthhkrhgvmhgvrhhssehfrghs thhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Original-Received: from Swift.fastmail.com (dhcp-129-70-105-144.dhcp.uni-bielefeld.de [129.70.105.144]) by mail.messagingengine.com (Postfix) with ESMTPA id D3F258005C for ; Thu, 29 Aug 2019 03:49:53 -0400 (EDT) In-reply-to: <87ftllji9u.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.29 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239667 Archived-At: Hi Roland, First, thanks for your answer. Perhaps I should have given some=20 background in my previous mail: I maintain a package called Ebib,=20 which implements a BibTeX database manager for Ebib. It uses some=20 of the functionality of bibtex.el (specifically, the entry type=20 definitions and the autokey machinery), which is how I (or rather,=20 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=20 >> 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=20 > the > elements can be treated as alternatives? Assuming that a=20 > bib(la)tex > entry has either a year or a date field, then=20 > bibtex-autokey-get-year > could use one or the other. Yes, that would be great. Biblatex requires that either date or=20 year be present, so it's a safe assumption that one of them will=20 be. Biblatex favours date over year, so I'd suggest date be=20 checked first. One thing to keep in mind is that the date field can contain a=20 full date + time, not just a year, and even date ranges, so in=20 order to produce a year part for the autokey, the date field needs=20 to be parsed. This shouldn't be too difficult, though, since the=20 format of the date field is clearly defined. (The biblatex doc has=20 all the details.) >> Second, it isn't clear to me how `bibtex-generate-autokey`=20 >> handles >> macros in titles, specifically \emph. > > I never had such a problem. Details probably depend on your use=20 > cases. > A generic parser for LaTeX code that can drop such things is=20 > probably > not all trivial. (But maybe something of that kind exists=20 > 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=20 something), but I do something like this in Ebib: In order to=20 display the title in a user-friendly manner, Ebib strips all TeX=20 commands from a title, leaving only the obligatory argument. (It=20 also does some fontification, BTW.) It works well enough for my=20 use-case, but it'll break in more complicated cases; e.g., it=20 doesn't take into account multiple obligatory arguments, and it=20 doesn't handle extensions to the default LaTeX syntax that some=20 packages (most notably biblatex...) implement, such as arguments=20 delimited with parentheses or pointy brackets, and optional=20 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.=20 >> Instead, I >> get the following error: >> >> bibtex-format-entry: Alternative mandatory field =E2=80=98(date year)=E2= =80=99=20 >> is >> missing > > I am not a biblatex expert. Since BibTeX mode picked up=20 > biblatex > support in 2013, it has treated the alternative fields date and=20 > year as > mandatory, see the default of bibtex-biblatex-entry-alist. Do=20 > you say > that these fields should be treated as crossref fields instead? Yes. In fact, both the BibTeX and the biblatex documentation state=20 that *all* fields are inherited if they are present in the parent=20 and not in the child. (With biblatex, this is a customisable=20 option, but it's on by default.) Obviously, for fields such as=20 author and title, inheriting them doesn't make much sense, but for=20 year and date it usually does. =20=20=20=20=20 BTW, `bibtex-generate-autokey` does in fact treat the year field=20 as inheritable. It's `bibtex-clean-entry` that protests when the=20 year field is missing. --=20 Joost Kremers Life has its moments