Four possible changes

[nxg]

I've suggested four changes here; feel free to cherry-pick.

1. test framework: this just creates a test/ directory, and a Makefile for managing regression tests
2. issue 1: it appears that this was already fixed in the upstream version, so this commit simply closes the issue
3. issue 2: trivial fix
4. implement eprints field prefixes.

The last may require thought: the eprints field is somewhat overloaded. It most often (at least in this community) refers to arXiv, but may also refer to ASCL.net (the journal A&C is encouraging this). It has been proposed (by me and others, and http://adswww.harvard.edu/ already implements this), that this can be resolved by supporting a prefix in the value. Thus eprints="arxiv:yyyy.nnnn" or eprints="ascl:yyyy.nnn" or the original, plain, eprints="yyyy.nnnn", referring to arXiv by default. The changes in the last commit implement this.

I (speaking as an A&C editor) will propose this eprints resolution to the journal manager, noting that this has proved implementable in fact.

[timj]

But ADS uses the archivePrefix field independently of eprint to indicate the source of the number.

[nxg]

Hmm, it seems I misremembered what ADS do. I see, though, that their archivePrefix doesn't actually do very much, and it's largely redundant in for example http://ads.harvard.edu/pubs/bibtex/astronat/apj/apj.bst

I'll take this up with Alberto when I ask him about ASCL+A&C

I still think that the prefix:ref is a good solution to indicating multiple repositories, but can't now point to as much precedent.

[timj]

So I think the logic is simply "does the eprint include a colon, if it does use it as is, else prepend the archivePrefix and if archivePrefix is not set just prepend with arXiv:"

[nxg]

That's fine for the formatting, but it doesn't add the repository URL. What we want (I think) is for eprint="arxiv:yyyy.nnnn" to generate the visible text {\tt arXiv:yyyy.nnnn} plus a link to http://arxiv.org/abs/yyyy.nnnn.

[timj]

yes there needs to be a URL but that can be derived from the archivePrefix field. Are you going to edit all the existing bib entries downloaded from ADS that don't have the archivePrefix in the eprint field?

[nxg]

No, I don't propose to edit other people's .bib entries, which would in any case be impossible. I don't see why you think I'd want to do that.

I think we may be talking at cross-purposes. I'm talking about supporting the proposed convention (and editorial suggestion) eprint="ascl:yyyy.nnn" in A&C articles, as was (possibly too much in passing) discussed in a recent exchange of emails, and has been discussed in the context of the mn2e style. You're the one who mentioned archivePrefix. That is indeed another way of indicating this sort of information.

[timj]

Ok, this is confusing. ADS currently use archivePrefix for ASCL and arXiv so obviously we need to support the ADS way of doing it. My logic above would work both ways (if there is a prefix don't add one, else add what is in archivePrefix).

My comment about rewriting bib files is that that is required if you are now insisting on ignoring archivePrefix and want the prefix included in eprint.

[nxg]

Parenthetically: I wanted to create another pull request, but github seems to have decided to add that one to this compendium one (no, I don't know either, how I got a compendium pull request...). Some cherry-picking will be in order. Ho hum.

[timj]

did you use the same branch?

[nxg]

Presumably. I'm pretty sure I tried to create a new branch for at least one of the changes, but it seems not to have taken. So github lumps them all together? Ho hum, indeed.

[timj]

Not unreasonably, if you make further commits to a branch Github assumes you are refining the existing pull request. Each pull request needs its own branch. Github doesn't expect you to be developing on branch master in your fork either.