Conflicts between easykeys and betterbibtexkeys about pandoc-zotxt.lua HOT 7 CLOSED

Thanks for reporting this. I'll have a look at it. zotxt may have changed the way it handles easy citekeys. I'm also under the impression that @egh has effectively retired them.

@egh, did you? I, for one, would be happy if you'd bring them back (the "you" indicating that I don't see myself finding the time to contribute a PR, sorry). Better BibTeX slows down Zotero's startup a lot. And there are only a few items in my library that are not uniquely identified by their author and the year they've been published in; I can take care of those manually.

As for trying Better BibTex keys before easy citekeys: Putting easykey last in ZOTXT_KEYTYPES may not do that reliably. If pandoc-zotxt.lua can't find an item that matches the given Better BibTeX key it will, eventually, try the same key as easy citekey, and if that works---which it might if the key has the structure <author>:<date><word from title>---, then pandoc-zotxt.lua will switch back to trying easy citekeys first. You can simply comment out the 'easykey' line to disable them completely.

from pandoc-zotxt.lua.

Hmm, zotxt appears to handle queries that match multiple items the way it used to.

% curl 'http://localhost:23119/zotxt/items?easykey=haslanger:2012construction'
haslanger:2012construction returned multiple items%

However, easykey queries also work with titles of the form "DoeTitle2021". Could it be that you happen to have a Better BibTeX citation key that uniquely identifies an item other than the one it is the citation key of if you derive from it a search query for that author, date, and title keywords?

There is no way to dinstingusih easy citekeys and Better BibTeX keys, so pandoc-zotxt.lua simply tries whether assuming that a citation key is of a given type yields a result. It does so for every key type, and the order in which it tries them simply depends on whether assuming that a key is of a given type yielded a result the last time.

from pandoc-zotxt.lua.

Could it be that you happen to have a Better BibTeX citation key that uniquely identifies an item other than the one it is the citation key of if you derive from it a search query for that author, date, and title keywords?

This, I think, is precisely what’s happening.

As to solutions, for me it’s perfectly ok to delete the easykey line from my local copy of the script. (So feel free to close this issue.)

One more general solution might be for pandoc-zotxt.lua to check whether BBT is running, and, if true, deactivate easykeys. If false, it might make sense to, in turn, deactivate betterbibtexkeys.

There might be other solutions, but I fould that checking whether BBT is running is possible by trying to fetch a bibliography without actually giving a collectionID, using curl http://127.0.0.1:23119/better-bibtex/collection. With BBT active, this returns Could not export bibliography: no path; otherwise No endpoint found.

Caveat: Replace portnumber 23119 with 24119 for Juris-M (see https://retorque.re/zotero-better-bibtex/exporting/pull/).

from pandoc-zotxt.lua.

I am trying to deprecate easykeys. I think BBT provides a much better solution. They are no longer mentioned in the documentation. I'm not planning to remove support from zotxt any time soon, though.

from pandoc-zotxt.lua.

Hmm, disabling easy citekeys when BBT is installed would break old documents that still use them. I'm leaning towards just 'demoting' easy citekeys, so that they are only tried when the BBT citation key does not match, and making keytypes configurable, so that users have a better way to resolve conflicts than editing the souce.

from pandoc-zotxt.lua.

I’ve released a new beta version that allows you to declare what type(s) of citation keys you want to use by setting a new metadata field zotero-citekey-types to the name of the citation key type that you want to use (or a list of such names). You can download it at https://github.com/odkr/pandoc-zotxt.lua/releases/tag/v1.1.0b3. Please give it a go and tell me what you think.

from pandoc-zotxt.lua.

Closing this because v1.1.0b7 is stable enough. I'll release it once I am sure it will work with the next release of Pandoc.

from pandoc-zotxt.lua.