unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Patrick M. Niedzielski <patrick@pniedzielski.net>
To: Lars Ingebrigtsen <larsi@gnus.org>, Ryan Kavanagh <rak@debian.org>
Cc: 36252@debbugs.gnu.org
Subject: bug#36252: 26.1; bibtex-generate-autokey does not use use date field
Date: Sat, 05 Dec 2020 09:20:52 +0000	[thread overview]
Message-ID: <87im9gpq17.fsf@pniedzielski.net> (raw)
In-Reply-To: <87pn6o766s.fsf@gnus.org>

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> skribis:
> Lars Ingebrigtsen <larsi@gnus.org> writes: 
> 
> This was five weeks ago, and there was no response, so I'm 
> closing this bug report.  If progress can be made here, please 
> respond to the debbugs mail address, and we'll reopen the bug 
> report. 

I’d like to reopen this bug, and submit the attached patch which I 
believe fixes the issue. This patch teaches 
‘bibtex-generate-autokey’ to prefer an ISO8601-formatted ‘date’ 
field when present, and fall back to a ‘year’, and is implemented 
using Lars’ ISO8601 parsing functions.

Just some implementation notes: I don’t believe Ryan’s original 
patch works as documented when ‘bibtex-autokey-use-crossref’ is 
non-nil.  In this case, his patch would seem to prefer a 
crossref’d entry’s ‘year’ field to a local entry’s ‘date’ field. 
More concretely, with the following BibLaTeX,

  @misc{doe1995some,
    title = {Some work},
    author = {John Doe},
    year = {1995},
    date = {1995-01-01},
  } 

  @misc{,
    title = {Another work},
    author = {Anon Y. Mous},
    date = {1990-03-12},
    crossref = {entry1},
  }

When generating a key for entry2, the original patch would prefer 
using the year 1995 to the year 1990, which is unintuitive. The 
attached patch implements a different behavior instead, in which 
an entry’s own ‘year/date’ field are prefered to the crossref’d 
entry’s ‘year/date’ field. In the above case, 
‘bibtex-generate-autokey’ will generate a entry key with the year 
1990 rather than 1995.

Additionally, we prefer to use the ‘date’ field when present over 
the ‘year’ field. This behavior is probably more correct, since 
BibLaTeX deprecated the ‘year’ field in favor of its own ‘date’ 
field, which only should occur in BibLaTeX-flavor files. Note that 
this is a breaking change from the prior behavior, but only when 
an entry has incompatible ‘date’ and ‘year’ fields.  If a file is 
meant to support both BibTeX and BibLaTeX, the ‘date’ and ‘year’ 
fields should contain the same information.

The attached patch implements the above behavior.

Best,
Patrick


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Prefer-date-field-to-year-field-in-BibTex-entry.patch --]
[-- Type: text/x-diff, Size: 3221 bytes --]

From 26cb162d42e7fd234506a5f847fbfb73adb68105 Mon Sep 17 00:00:00 2001
From: "Patrick M. Niedzielski" <patrick@pniedzielski.net>
Date: Sun, 29 Nov 2020 02:09:47 +0000
Subject: [PATCH] Prefer date field to year field in BibTex entry

The bibtex.el package contains functionality to automatically generate
a key for a BibTeX entry using author/editor, year, and title
information in the entry.  The BibLaTeX dialect has deprecated the
'year' field (and 'month') in favor of an ISO8601-formatted 'date'
field.  This patch teaches the 'bibtex-generate-autokey' function to
prefer a 'date' field when present, and fall back to a 'year' field
for bibtex compatibility.
---
 lisp/textmodes/bibtex.el | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/lisp/textmodes/bibtex.el b/lisp/textmodes/bibtex.el
index c9e21e58f6..fe468d261d 100644
--- a/lisp/textmodes/bibtex.el
+++ b/lisp/textmodes/bibtex.el
@@ -2751,10 +2751,16 @@ and `bibtex-autokey-names-stretch'."
              (bibtex-autokey-abbrev name bibtex-autokey-name-length))))
 
 (defun bibtex-autokey-get-year ()
-  "Return year field contents as a string obeying `bibtex-autokey-year-length'."
-  (let ((yearfield (bibtex-autokey-get-field "year")))
-    (substring yearfield (max 0 (- (length yearfield)
-                                   bibtex-autokey-year-length)))))
+  "If date field exists, return year component of the ISO8601-formatted
+date field contents as a string obeying `bibtex-autokey-year-length'.
+Otherwise, return year field contents as a string obeying
+`bibtex-autokey-year-length'."
+  (let* ((yearfield (bibtex-autokey-get-field "year\\|date"))
+         (dateyear  (if (iso8601-valid-p yearfield)
+                        (decoded-time-year (iso8601-parse yearfield))
+                      nil))
+         (year      (if dateyear (number-to-string dateyear) "")))
+    (substring year (max 0 (- (length year) bibtex-autokey-year-length)))))
 
 (defun bibtex-autokey-get-title ()
   "Get title field contents up to a terminator.
@@ -2837,12 +2843,16 @@ The name part:
 
 The year part:
  1. Build the year part of the key by truncating the content of the year
-    field to the rightmost `bibtex-autokey-year-length' digits (useful
-    values are 2 and 4).
- 2. If the year field (or any other field required to generate the key)
-    is absent, but the entry has a valid crossref field and
-    `bibtex-autokey-use-crossref' is non-nil, use the field of the
-    crossreferenced entry instead.
+    component of the ISO8601-formatted date field to the rightmost
+    `bibtex-autokey-year-length' digits (useful values are 2 and 4).
+ 2. If the date field is absent, but the entry has a year field, build the
+    year part of the key by truncating the year field to the rightmost
+    `bibtex-autokey-year-length' digits.
+ 3. If both the year field and the date field (or any other field
+    required to generate the key) are absent, but the entry has a
+    valid crossref field and `bibtex-autokey-use-crossref' is
+    non-nil, use the date or year field of the crossreferenced entry
+    instead.
 
 The title part
  1. Change the content of the title field according to
-- 
2.29.2


  reply	other threads:[~2020-12-05  9:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-16 20:23 bug#36252: 26.1; bibtex-generate-autokey does not use use date field Ryan Kavanagh
2019-07-06 14:52 ` Lars Ingebrigtsen
2019-07-06 14:55 ` Lars Ingebrigtsen
2019-07-15  0:34   ` Ryan Kavanagh
2019-07-15  7:24     ` Lars Ingebrigtsen
2019-09-16 21:01       ` Lars Ingebrigtsen
2020-08-10 11:01         ` Lars Ingebrigtsen
2020-09-14 15:02           ` Lars Ingebrigtsen
2020-12-05  9:20             ` Patrick M. Niedzielski [this message]
2020-12-06  9:25               ` Colin Baxter
2020-12-07  6:18                 ` Roland Winkler
2020-12-06 13:19               ` Lars Ingebrigtsen
2020-12-07  6:20                 ` Roland Winkler
2020-12-07 15:14                   ` Lars Ingebrigtsen
2020-12-11 15:04                   ` 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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87im9gpq17.fsf@pniedzielski.net \
    --to=patrick@pniedzielski.net \
    --cc=36252@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=rak@debian.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).