From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Roland Winkler Newsgroups: gmane.emacs.devel Subject: Re: BibTeX issues Date: Fri, 30 Aug 2019 14:18:00 -0500 Message-ID: <87blw6jwd3.fsf@gnu.org> References: <87mufv2e9s.fsf@uni-bielefeld.de> <87ftllji9u.fsf@gnu.org> <87o908tnq8.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="36768"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: emacs-devel@gnu.org To: Joost Kremers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 30 21:18:43 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 1i3mPw-0009OY-Hs for ged-emacs-devel@m.gmane.org; Fri, 30 Aug 2019 21:18:40 +0200 Original-Received: from localhost ([::1]:40706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3mPv-0003hf-DN for ged-emacs-devel@m.gmane.org; Fri, 30 Aug 2019 15:18:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44333) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3mPR-0003hX-T6 for emacs-devel@gnu.org; Fri, 30 Aug 2019 15:18:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i3mPR-0006E6-Nz; Fri, 30 Aug 2019 15:18:09 -0400 Original-Received: from 162-229-45-114.lightspeed.cicril.sbcglobal.net ([162.229.45.114]:37916 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1i3mPR-0000kg-ET; Fri, 30 Aug 2019 15:18:09 -0400 In-Reply-To: <87o908tnq8.fsf@fastmail.fm> (Joost Kremers's message of "Thu, 29 Aug 2019 09:49:51 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239711 Archived-At: 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.