joostkremers / ebib

A BibTeX database manager for Emacs.
https://joostkremers.github.io/ebib/
BSD 3-Clause "New" or "Revised" License
272 stars 37 forks source link

Cannot specify unknown date #260

Open jb-stack opened 2 years ago

jb-stack commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

You're right, I hadn't noticed. :smile: 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 commented 2 years ago

@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 commented 2 years ago

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