[PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[Leo Stein]

[-- Attachment #1.1: Type: text/plain, Size: 272 bytes --]

This is a fairly trivial patch: the eprint field (like doi and url fields)
is another field with (AFAIK) a universal format that maps to a URL. This
makes the contents of the eprint field automatically linked to the arXiv
eprint associated to the bibtex entry.

Best,
Leo

[-- Attachment #1.2: Type: text/html, Size: 328 bytes --]

[-- Attachment #2: 0001-BibTeX-mode-add-eprint-field-as-potential-source-for.patch --]
[-- Type: application/octet-stream, Size: 815 bytes --]

From 56ae41b168b75b7fc036a68e08802de3b2cb4cb2 Mon Sep 17 00:00:00 2001
From: "Leo C. Stein" <leo.stein@gmail.com>
Date: Sun, 1 Dec 2024 12:49:46 -0600
Subject: [PATCH] BibTeX-mode: add eprint field as potential source for entry's
 URL

---
 lisp/textmodes/bibtex.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/textmodes/bibtex.el b/lisp/textmodes/bibtex.el
index 99a97c9bb8d..c77953489a7 100644
--- a/lisp/textmodes/bibtex.el
+++ b/lisp/textmodes/bibtex.el
@@ -1443,6 +1443,9 @@ Used by `bibtex-complete-crossref-cleanup' and `bibtex-copy-summary-as-kill'."
 
 (defcustom bibtex-generate-url-list
   '((("url" . ".*:.*"))
+    (("eprint" . ".*")
+     "https://arxiv.org/abs/%s"
+     ("eprint" ".*" 0))
     (("doi" . "10\\.[0-9]+/.+")
      "https://doi.org/%s"
      ("doi" ".*" 0)))
-- 
2.47.0

Re: [PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[Eli Zaretskii]

> From: Leo Stein <leo.stein@gmail.com>
> Date: Sun, 1 Dec 2024 13:05:33 -0600
> 
> This is a fairly trivial patch: the eprint field (like doi and url fields) is another field with (AFAIK) a universal
> format that maps to a URL. This makes the contents of the eprint field automatically linked to the arXiv eprint
> associated to the bibtex entry.
> 
> Best,
> Leo
> 
> From 56ae41b168b75b7fc036a68e08802de3b2cb4cb2 Mon Sep 17 00:00:00 2001
> From: "Leo C. Stein" <leo.stein@gmail.com>
> Date: Sun, 1 Dec 2024 12:49:46 -0600
> Subject: [PATCH] BibTeX-mode: add eprint field as potential source for entry's
>  URL
> 
> ---
>  lisp/textmodes/bibtex.el | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lisp/textmodes/bibtex.el b/lisp/textmodes/bibtex.el
> index 99a97c9bb8d..c77953489a7 100644
> --- a/lisp/textmodes/bibtex.el
> +++ b/lisp/textmodes/bibtex.el
> @@ -1443,6 +1443,9 @@ Used by `bibtex-complete-crossref-cleanup' and `bibtex-copy-summary-as-kill'."
>  
>  (defcustom bibtex-generate-url-list
>    '((("url" . ".*:.*"))
> +    (("eprint" . ".*")
> +     "https://arxiv.org/abs/%s"
> +     ("eprint" ".*" 0))
>      (("doi" . "10\\.[0-9]+/.+")
>       "https://doi.org/%s"
>       ("doi" ".*" 0)))
> -- 
> 2.47.0
> 

Roland, any comments?

Re: [PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[Roland Winkler]

On Sun, Dec 01 2024, Eli Zaretskii wrote:
>> diff --git a/lisp/textmodes/bibtex.el b/lisp/textmodes/bibtex.el
>> index 99a97c9bb8d..c77953489a7 100644
>> --- a/lisp/textmodes/bibtex.el
>> +++ b/lisp/textmodes/bibtex.el
>> @@ -1443,6 +1443,9 @@ Used by `bibtex-complete-crossref-cleanup' and `bibtex-copy-summary-as-kill'."
>>  
>>  (defcustom bibtex-generate-url-list
>>    '((("url" . ".*:.*"))
>> +    (("eprint" . ".*")
>> +     "https://arxiv.org/abs/%s"
>> +     ("eprint" ".*" 0))
>>      (("doi" . "10\\.[0-9]+/.+")
>>       "https://doi.org/%s"
>>       ("doi" ".*" 0)))
>
> Roland, any comments?

The above patch is very arXiv-specific.  All this goes beyond
old-fashioned BibTeX.  But the documentation for biblatex (current:
version 3.20 from CTAN) says in Sec. 3.14.7 "Electronic Publishing
Information" how the field "eprint" should be used in combination with a
field "eprinttype" to identify an electronically published document.
Arxiv's usage is not compatible with this.  Instead of "eprinttype"
arXiv uses a field "archivePrefix", and the field "primaryClass" used by
arXiv should probably be replaced by the optional field "eprintclass"
mentioned in the biblatex documentation.

To the best of my knowledge, neither the arXiv approach nor the different
approach suggested by the biblatex documentation have found a widespread
use in real life.

The user variable bibtex-generate-url-list can be configured to work
either way, as suggested by the OP or as suggested by the biblatex
documentation.  Here it seems to me the best solution is to keep the
default of bibtex-generate-url-list as it is now and let users configure
this variable as desired / needed.

Note also that arXiv also provides a field "url" that is already
supported by the default value of bibtex-generate-url-list.

Re: [PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[Eli Zaretskii]

> From: Roland Winkler <winkler@gnu.org>
> Cc: Leo Stein <leo.stein@gmail.com>,  emacs-devel@gnu.org
> Date: Mon, 02 Dec 2024 07:08:20 -0600
> 
> On Sun, Dec 01 2024, Eli Zaretskii wrote:
> >> diff --git a/lisp/textmodes/bibtex.el b/lisp/textmodes/bibtex.el
> >> index 99a97c9bb8d..c77953489a7 100644
> >> --- a/lisp/textmodes/bibtex.el
> >> +++ b/lisp/textmodes/bibtex.el
> >> @@ -1443,6 +1443,9 @@ Used by `bibtex-complete-crossref-cleanup' and `bibtex-copy-summary-as-kill'."
> >>  
> >>  (defcustom bibtex-generate-url-list
> >>    '((("url" . ".*:.*"))
> >> +    (("eprint" . ".*")
> >> +     "https://arxiv.org/abs/%s"
> >> +     ("eprint" ".*" 0))
> >>      (("doi" . "10\\.[0-9]+/.+")
> >>       "https://doi.org/%s"
> >>       ("doi" ".*" 0)))
> >
> > Roland, any comments?
> 
> The above patch is very arXiv-specific.  All this goes beyond
> old-fashioned BibTeX.  But the documentation for biblatex (current:
> version 3.20 from CTAN) says in Sec. 3.14.7 "Electronic Publishing
> Information" how the field "eprint" should be used in combination with a
> field "eprinttype" to identify an electronically published document.
> Arxiv's usage is not compatible with this.  Instead of "eprinttype"
> arXiv uses a field "archivePrefix", and the field "primaryClass" used by
> arXiv should probably be replaced by the optional field "eprintclass"
> mentioned in the biblatex documentation.
> 
> To the best of my knowledge, neither the arXiv approach nor the different
> approach suggested by the biblatex documentation have found a widespread
> use in real life.
> 
> The user variable bibtex-generate-url-list can be configured to work
> either way, as suggested by the OP or as suggested by the biblatex
> documentation.  Here it seems to me the best solution is to keep the
> default of bibtex-generate-url-list as it is now and let users configure
> this variable as desired / needed.

I agree.  Since this is a user option, too-specific changes in it
should be the matter of the user, not of changing the default.

Re: [PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[Leo Stein]

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

Dear all,

First of all, Roland, thanks again for your continued maintenance of this
useful mode, and Eli, thanks for your maintenance of all of emacs!

On Mon, Dec 2, 2024 at 7:34 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Roland Winkler <winkler@gnu.org>
> > Cc: Leo Stein <leo.stein@gmail.com>,  emacs-devel@gnu.org
> > Date: Mon, 02 Dec 2024 07:08:20 -0600
> >
> > On Sun, Dec 01 2024, Eli Zaretskii wrote:
> > >> diff --git a/lisp/textmodes/bibtex.el b/lisp/textmodes/bibtex.el
> > >> index 99a97c9bb8d..c77953489a7 100644
> > >> --- a/lisp/textmodes/bibtex.el
> > >> +++ b/lisp/textmodes/bibtex.el
> > >> @@ -1443,6 +1443,9 @@ Used by `bibtex-complete-crossref-cleanup' and
> `bibtex-copy-summary-as-kill'."
> > >>
> > >>  (defcustom bibtex-generate-url-list
> > >>    '((("url" . ".*:.*"))
> > >> +    (("eprint" . ".*")
> > >> +     "https://arxiv.org/abs/%s"
> > >> +     ("eprint" ".*" 0))
> > >>      (("doi" . "10\\.[0-9]+/.+")
> > >>       "https://doi.org/%s"
> > >>       ("doi" ".*" 0)))
> > >
> > > Roland, any comments?
> >
> > The above patch is very arXiv-specific.



Yes, this is arXiv-specific. I know that there are other eprint servers out
there (e.g. biorXiv, chemrXiv).

Before submitting the patch, I grepped through the latest TeX Live tree to
find which bst's used the eprint field. As far as I could tell, bib styles
assume that the eprint field points to the arXiv, not to a different
preprint server. So, as far as I can tell, in actual practice, an eprint
field always means the arXiv.


> All this goes beyond
> > old-fashioned BibTeX.  But the documentation for biblatex (current:
> > version 3.20 from CTAN) says in Sec. 3.14.7 "Electronic Publishing
> > Information" how the field "eprint" should be used in combination with a
> > field "eprinttype" to identify an electronically published document.
>

This is independent of bibtex vs. biber+biblatex.


> > Arxiv's usage is not compatible with this.  Instead of "eprinttype"
> > arXiv uses a field "archivePrefix", and the field "primaryClass" used by
> > arXiv should probably be replaced by the optional field "eprintclass"
> > mentioned in the biblatex documentation.
>

I am not focusing on .bib files generated by the arXiv itself. I usually
get my .bib entries from INSPIRE, or ADS, or sometimes the AMS's
mathscinet, or zbMath, or Google Scholar. I know that I do not have the
broadest possible cross-section of biblio databases under my belt ... but
as the arXiv and thus the idea of online preprint servers was created by
physicists, I think this is a pretty representative view of .bib usage in
the wild. Physicists, mathematicians, and computer scientists use LaTeX and
thus bibtex more so than other specialties. Within these ecosystems, my
understanding is that the eprint field refers to the arXiv.


> >
> > To the best of my knowledge, neither the arXiv approach nor the different
> > approach suggested by the biblatex documentation have found a widespread
> > use in real life.
>

This is not true — the eprint field, archivePrefix, and primaryClass are
used by the arXiv, INSPIRE, and ADS. I could check the others if you'd like.


> >
> > The user variable bibtex-generate-url-list can be configured to work
> > either way, as suggested by the OP or as suggested by the biblatex
> > documentation.  Here it seems to me the best solution is to keep the
> > default of bibtex-generate-url-list as it is now and let users configure
> > this variable as desired / needed.
>

Of course I've customized the variable for myself. But it took me years
before I realized "Hey, wait a minute, why can't I click on the arXiv
number?", and then dug through the mode docs to discover that it's possible
to customize this.

I'm just proposing a tiny change which will reduce a little friction for
many people [most of whom I think wouldn't investigate that they can
customize this]. I don't know that including this universal default would
ever be "wrong".

I hope you'll keep an open mind to consider the patch.

Best
Leo


>
> I agree.  Since this is a user option, too-specific changes in it
> should be the matter of the user, not of changing the default.
>

[-- Attachment #2: Type: text/html, Size: 6441 bytes --]

Re: [PATCH] BibTeX-mode: add eprint field as potential source for entry's URL

[Roland Winkler]

On Mon, Dec 02 2024, Leo Stein wrote:
> > All this goes beyond old-fashioned BibTeX.  But the documentation
> > for biblatex (current: version 3.20 from CTAN) says in Sec. 3.14.7
> > "Electronic Publishing Information" how the field "eprint" should be
> > used in combination with a field "eprinttype" to identify an
> > electronically published document.
>
> This is independent of bibtex vs. biber+biblatex.

The documentation for these programs defines the defaults implemented
via user variables of bibtex-mode.  You are free to customize these
variables.

> Physicists, mathematicians, and computer scientists use LaTeX and thus
> bibtex more so than other specialties.

It is beyond me to comment.

> Of course I've customized the variable for myself. But it took me
> years before I realized "Hey, wait a minute, why can't I click on the
> arXiv number?", and then dug through the mode docs to discover that
> it's possible to customize this.

We are talking here about Emacs where 10 users may strongly advocate 20
different "most obvious" ways to change the behavior of Emacs.