Closed yakatz closed 1 month ago
Is L4N78GU6-refs-euc/6.7.222-7
from the Win10 or the Win11 computer? Can you add a debug log for the other computer?
Without further input I'm going to have to close the issue.
Sorry for the delay, I didn't see my email.
L4N78GU6-refs-euc/6.7.222-7
is from the Windows 10 computer.
3G29GQ56-refs-euc/6.7.225-7
is from the Windows 11 computer.
I can't yet reproduce this. A build will drop here in 10 minutes that adds logging -- please generate a new log on both systems.
:robot: this is your friendly neighborhood build bot announcing test build 6.7.226.6856 ("add logging")
This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 6.7.226.6856, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".
New debug log from Windows 10 computer: P9D9UPAC-euc/6.7.226.6856-7
I will send the Windows 11 log shortly.
Windows 11 debug log: W7L52QCH-euc/6.7.226.6856-7
I don't see items being changed or keys being refreshed in either log.
Can you refresh the keys on both systems and then send a log?
When I force refreshed the key on the Windows 11 computer, it went from UPSSCalculatorV09
to UPSSCalculatorV0
, so that is consistent with the Windows 10 one (although not what I would like - I know I can change it manually). It wasn't showing as pinned before and I am sure I didn't change it manually, so I don't know why it would be different.
Log from Windows 11: U74NN3L6-refs-euc/6.7.226.6856-7
It wasn't showing as pinned before and I am sure I didn't change it manually, so I don't know why it would be different.
Only thing I can think of is that it might be really old and I've fixed the key formatter since. Keys stay the same unless the item changes, a fix in the formatter would not affect that.
I guess I will pin it to the value I used in the actual paper. Sorry for the confusion.
No problem.
Hopefully this wouldn't break backwards compatibility, but what would be the chance of allowing punctuation to be considered part of a word, maybe if it isn't followed by trailing whitespace, or maybe of the regex for word
recognizing \d+\.\d+
as a single word instead of splitting on the period?
(Based on what I understand of https://github.com/retorquere/zotero-better-bibtex/blob/0824ceb6bf27c21b8803310cb7ed700b05a7d521/content/key-manager/formatter.ts#L1424-L1426)
And was this what caused the change? https://github.com/retorquere/zotero-better-bibtex/commit/4dcccbbb45e64c229004eae2334782109123d570
:robot: this is your friendly neighborhood build bot announcing test build 6.7.226.6889 ("simplify")
This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 6.7.226.6889, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".
And was this what caused the change? 4dcccbb
That will be it.
Hopefully this wouldn't break backwards compatibility, but what would be the chance of allowing punctuation to be considered part of a word, maybe if it isn't followed by trailing whitespace, or maybe of the regex for
word
recognizing\d+\.\d+
as a single word instead of splitting on the period?
That's in the new build. You can test it but it passes my tests so I'm going to release it when I have a few more other issues ironed out.
This works for me. Thank you.
Debug log ID
L4N78GU6-refs-euc/6.7.222-7
What happened?
I have a
dataset
item with the titleUPSS Calculator v0.9
. On my computer running Windows 11, the generated citation key isUPSSCalculatorV09
. On my computer running Windows 10 (where this debug was generated), the citation key isUPSSCalculatorV0
. (I found this after changing my sort order and seeing what changes were still shown ongit diff
- see #2952)