conditional citekey formatting/zotero year field

[kaymmm]

Related to this discussion: https://forums.zotero.org/discussion/57748/betterbibtex-multiple-patterns/

I was hoping to try the test build you created for the linked discussion, but it's unfortunately gone and the citekey format entry in 1.6.45 doesn't like the [>0] option that you added in that test build. I saw that it's available in the shortcut branch and was wondering if there are plans to integrate it into master.

Alternatively (and apologies if this should be a separate issue), the default [zotero] formatter works in the majority of instances, however it breaks pandoc when the date fields are empty and the parser returns ????.

One possible fix for the [zotero] formatter might be to tweak this line to use something like ND or an empty string when a source has no date, but I know this would probably screw up a lot of people's existing citekeys that aren't pinned and is generally not a good idea unless an additional setting is added to make this opt-in. Any other suggestions?

[retorquere]

I didn't want to merge to master without confirmation from a user that it worked to their satisfaction, and test builds disappear after about a week because a) I don't want people to ever use too old test builds, and b) I need to know who's using them because they will automatically upgrade to a newer release if I put one out, and stuff would break if you expect that debug version to stay in place. I've put up an updated version that has the [>n] syntax here -- it will also have a few things that I'm prepping for release, but all existing tests pass. For clarity, it means "if what came before has more than n characters, proceed building the key, otherwise, try the next pattern".

I don't want to tweak the zotero formatter. It's sole raison d'être is to exactly duplicate the zotero key builder, warts and all¹, to help people who have existing bibliographies, but if the stock BibTeX translators update, I'll follow suit.

For more complicated things, there's export postscripts; I don't want the pattern language to evolve into a programming language of its own, but manipulating the citation key from the postscript is not something you want to do without having a full understanding of its limitations. The citekey is the one piece of info a postscript can change that could really yield funny stuff.

¹ with one exception, because that's outside what pattern formatters can affect, and that's generating duplicate keys. It would be too invasive to replicate that wart.

[kaymmm]

Awesome, thank you! I'll check it out later today and report back on the >n functionality.

[retorquere]

So...

[retorquere]

Any feedback?

[kaymmm]

Sorry, didn't have a chance to check yesterday. I tried it with a few different combos and it works for the case of >0 as an exists/does not exist conditional, but I couldn't get it working with authors >1+ to see if there were multiple authors. Doesn't matter for my purposes, but wanted to report for thoroughness.

[retorquere]

the '>' filter is character-based, not object-based, so it can't detect multiple authors, just length of string so far.

[retorquere]

object-based is not in the cards. If character-based is useful, I can merge this and release it, otherwise I'm just keeping this on a separate branch for now.

[retorquere]

So, in or out on this feature? This issue being open is the one thing deferring the next release now.

[kaymmm]

My apologies, didn't see your previous message until just now. I definitely think it should go in the next release. It's useful and works with all of the cases that I've thrown at it.

[kaymmm]

tl;dr: citekey generation using [>0] formatting is broken since 1.6.51 (or maybe .52). Works in 1.6.50.

There's something a bit wonky going on recently with the generation and display of citation keys that may or may not be related to #497, but I'm pretty sure it's related to the [>0] citation format which is why I'm adding to this issue.

In general, it seems that citation keys are not being auto-generated, and right-clicking to generate a citation key does nothing. At least, that's what I think. They're definitely not being displayed in the Extra or Citation Key fields.

The reason I can't quite figure things out is that I just tried going back through previous releases one-by-one until I hit 1.6.50. The issue persisted through all of the recent versions until I went back to 1.6.50, when it seemed like the auto-generation of citation keys was working correctly.

When I checked the .bib file that is being automatically sync'd (tried with all methods of manual/change/idle), entries for newly added items are not being generated unless the citekey generates correctly. Everything seems to be working correctly with 1.6.50.

I'm using the citekey format: [auth][>0][year]|[veryshorttitle][year]. This had been working since the [>0] format option was merged a month ago. Using [zotero] as the format seems to be working as expected. If I just use something like [auth][year] it works as expected, but obviously not if the author field is empty.

I submitted an error report, report ID: M62BNEU3

When I try to generate a citation key, the debug error that's generated is:

JavaScript Error: "TypeError: longest.replace is not a function"

If I manually add a bibtex: SomeKey to the "extra" field, it will sometimes stick, but even that has been problematic as the "citation key" field will remain blank until I change the "extra" field a couple of times, and sometimes requires me to restart Zotero.

I'm having the same problem on both standalone and zotero-ffx.

[kaymmm]

also, please let me know if I should open a new issue instead of posting to this closed thread. apologies in advance...and thank you for all your work on this essential plugin!

[retorquere]

Please do open a new issue. It's very hard for me to keep track of what happens in closed issues.