Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot specify unknown date #260

Open
jb-stack opened this issue Jul 2, 2022 · 5 comments
Open

Cannot specify unknown date #260

jb-stack opened this issue Jul 2, 2022 · 5 comments

Comments

@jb-stack
Copy link

jb-stack commented Jul 2, 2022

When adding a biblatex entry where date / year is a required field, there does not appear to be a way to handle cases where the date / year is unavailable (as is quite common for example with web articles). I've tried leaving the date / year fields blank as well as trying the following values: nodate, n.d., nd, unknown, none, nil, n/a.

This results in e.g. the following message displaying when exiting the entry:

Year or date field 'nodate' is invalid

It also means that the entry does not get an auto-generated key.

I was unable to find anything in the manual which addresses this issue, but perhaps I missed something?

EDIT: I did some Googling and came across section 2.3.8 on page 39 of this which states that "Date fields [...] adhere to ISO8601-2 Extended Format specification level 1". According to this description of the ISO standard, it should be possible to enter an unspecified date (or partially unspecified date) using the character 'X' to replace the unspecified digits e.g.:

XXXX
20XX
2022-07-XX

However, all of the above examples generate the same error as my earlier attempts.

@joostkremers
Copy link
Owner

joostkremers commented Jul 2, 2022

It's actually bibtex.el that's responsible for this error, not Ebib. Ebib uses the function bibtex-generate-autokey to generate a key for a new entry, and it's this function (or, more specifically bibtex-autokey-get-year, which is called by bibtex-generate-autokey) that complains, because it's looking for a valid ISO 8601 date or something with a sequence of four numbers.

I'm pretty sure this is fairly new behaviour, though, because I've created entries in the past without a year and never encountered this error.

So it seems bibtex.el has become less permissive in this regard. I'll probably need to wrap the call to bibtex-generate-autokey in a condition-case and handle any user-error generated by it.

Thanks for bringing this to my attention. I'll need to think a bit about how to handle this best.

For your immediate case, you could use either 0000 or 9999 to indicate unknown years, which isn't pretty but it's better than nothing.

For a more general solution, though, I'll first need to check which errors can happen and if it's possible for Ebib to distinguish them, then figure out how to best handle them. The best way would probably be for Ebib to ignore the problem and generate a key anyway, but I'm not sure that's doable, given that bibtex-generate-autokey simply won't return a key if the year is missing. The alternative would be to prompt the user for a key.

@jb-stack
Copy link
Author

jb-stack commented Jul 2, 2022

it's this function (or, more specifically bibtex-autokey-get-year, which is called by bibtex-generate-autokey) that complains, because it's looking for a valid ISO 8601 date or something with a sequence of four numbers.

Thanks for your quick reply. In case you didn't spot it, I edited my first post shortly before your reply to include some ISO 8601 information relating to unspecified date digits using the character X. So perhaps bibtex.el is not actually fully compliant with the standard.

@joostkremers
Copy link
Owner

You're right, I hadn't noticed. 😄 bibtex.el uses iso6801-valid-p to do the testing, and indeed, (iso8601-valid-p "20XX") returns nil.

Such dates don't seem to be part of the base standard, but they are part of an extension, though I'm not sure to what extent it's "standard"... I'll ask on the Emacs mailing list to see how the devs feel about supporting this.

@Hugo-Heagren
Copy link
Contributor

@joostkremers sure you've thought of this already, but my suggestion would be to add an optional arg to iso8601-valid-p, specifying whether/which certain extensions are to be included in the check. Not sure how this could be implemented, but I could have a look. Just my two cents.

@joostkremers
Copy link
Owner

@Hugo-Heagren Sure, but it's not my code. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants