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

[Leo Stein <leo.stein@gmail.com>]

[-- 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 --]