search

retorquere / zotero-better-bibtex

Make Zotero effective for us LaTeX holdouts
https://retorque.re/zotero-better-bibtex/
MIT License
5.29k stars 284 forks source link

Suppress brace protection #1139

Closed jdhauck closed 5 years ago

jdhauck commented 5 years ago

Is there any way to prevent Better BibLaTeX from applying the protective double braces? I have read and understood the explanation here https://retorque.re/zotero-better-bibtex/faq/#bbt-is-changing-the-capitalization-of-my-titles--why However, given that Zotero doesn't automatically put titles in sentence case upon import (yet?) while there are way too many websites that provide bib data titles in titlecase, I frequently get those titles protected with double braces.

Why don't I edit titles in Zotero first? Well, my workflow is the following: I use zot2bib to automatically push Zotero data to BibDesk (I manage my .bib file through BibDesk), so there is no intermediate step where I could manually put the title in Zotero in sentence case before export. (In BibDesk I have a keyboard shortcut to protect words that need them for those titles already in title case and there is an AppleScript that automatically titlecases and protects those in sentence case.)

So, is there any way to not have BBT apply any braces?

retorquere commented 5 years ago

There currently isn't a way to prevent the braces, but I'm not quite grasping how your setup works. When you says "I use zot2bib to automatically push Zotero data to BibDesk", does that mean that when you add any new reference to Zotero, it automatically pushes that through to BibDesk? And zot2bib uses BBT to generate the BibTeX? So zot2bib just uses Zotero as a scraper. Reason I'm asking is that the zot2bib site talks about a button you should push to do all this -- if you have to push a button you could edit the title before pushing it right?

jdhauck commented 5 years ago

Yes, your are right, zot2bib uses Zotero for getting data from the browser and then directly pushes it to BibDesk. But there is no way to edit the title (by "pushing a button" George is referring to pushing the button of the Zoter browser plugin ... as soon as a new entry is added to Zotero, it is automatically pushed to BibDesk). Maybe a hidden preference could let the user prevent the braces? :)

retorquere commented 5 years ago

I'm considering it. Not a great fan, obviously.

blip-bloop commented 5 years ago

:robot: this is your friendly neighborhood build bot announcing test build 5.1.58.3534 ("allow people to shoot themselves in the foot")

Install in Zotero by downloading test build 5.1.58.3534, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

retorquere commented 5 years ago

The hidden pref is suppressNoCaseInference.

jdhauck commented 5 years ago

This is great, thank you! Now I can happily continue to shoot myself in the foot (ouch) ;)

Just one more thing: It still adds braces for Publisher and Location ... do you think these could also be omitted?

In general, I must admit I would hope BibLaTeX would at some point come around and implement a solution to store titles in sentence case, so this insane translation back and forth wouldn't be necessary anymore. :/ ...

retorquere commented 5 years ago

It should work everywhere, it just disabled no-case inference for words with uppercase letters. Can you right-click a reference that doesn't work for you and send a BBT error report?

retorquere commented 5 years ago

(the exception to "everywhere" being that if you have <span class="nocase"> in your items, that will still be honored, but in your case it's extremely unlikely to be there)

jdhauck commented 5 years ago

Just submitted the error report (for the same item, BTW, that also shows up as "collection" in our other thread). ID is WVKXIW2D-euc

But I've tested with books from worldcat, google, and amazon, and in all cases Location and Publisher have one extra set of braces around the whole string (not double braces, though).

retorquere commented 5 years ago

Oh around the whole field. Yeah, location and publisher are literal lists per the biblatex spec, not literal fields, and adding the extra braces makes sure that single entry (since Zotero can have only one) is treated as a single entity rather than accidentally being broken up if the contents contains and. BibDesk should handle that just fine, no?

jdhauck commented 5 years ago

I wasn't aware of that. Hmm, ok, I guess it makes sense, although I never ran into a problem with "and" which I'm protecting in the few cases where a publisher has an and. In location the and allows for some flexibility in printing either one or all of the locations (like if we have "London and New York", some styles want just "London" and others both.

retorquere commented 5 years ago

Oh trust me it was news to me at some point. BibLaTeX is insanely complex I've learned over the years. I trust on actual biblatex experts in my network to make the right call most of the time -- I'm much better at javascript than I am at biblatex.

It is correct that the and allows for flexibility, but it represents a flexibility Zotero doesn't have (like multiple publishers). If you want I can look at an option that would make it always behave as if it were #LaTeX tagged, maybe that's more helpful for you (I think... I haven't used that in ages so I'd have to look what it all affects).

jdhauck commented 5 years ago

Yeah if there's an option for it to always behave as LaTeX that'd be great!

retorquere commented 5 years ago

Turns out it should already be possible by setting the hidden pref rawLaTag to *.

retorquere commented 5 years ago

Does that work for you?

jdhauck commented 5 years ago

Hmm, setting the hidden pref doesn't seem to have any effect. The Publication and Location fields still get the extra braces ...

blip-bloop commented 5 years ago

:robot: this is your friendly neighborhood build bot announcing test build 5.1.58.3546 ("adjust test case for #1139")

Install in Zotero by downloading test build 5.1.58.3546, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

retorquere commented 5 years ago

Try with 3546

jdhauck commented 5 years ago

Apologies for my two weeks delay in responding back, due to family reasons.

I wanted to try the new built out but it seems that test build 5.1.58.3546 is no longer available :/

However, with the current release, setting the hidden pref rawLaTag to * obviously also prevents BBT from using the hidden prefs for ascii, csquotes, etc.
so, even if it ends up working, it'll interfere with other functionality that I'm using :/ Any ideas?

blip-bloop commented 5 years ago

:robot: this is your friendly neighborhood build bot announcing test build 5.1.60.3601 ("Merge branch 'master' into 1139")

Install in Zotero by downloading test build 5.1.60.3601, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

retorquere commented 5 years ago

Builds expire because I don't want people to hang on to them too long, but try 3601

jdhauck commented 5 years ago

Yeah, I suspected that. Thanks for reopening that.

OK, so with this build preventing braces by setting rawLaTag to * works.

But this now also prevents BBT from using hidden prefs for ascii, csquotes, and other goodies that I very much appreciate.
Any alternative ideas?

retorquere commented 5 years ago

Right, sorry -- you don't have to change rawLaTag, set suppressNoCaseInference to true.

jdhauck commented 5 years ago

Hmm, unfortunately with built 3601 and suppressNoCaseInference set to true I still get the extra braces around publisher and location fields ... :/

retorquere commented 5 years ago

A new build will be announced shortly, the preference has changed to suppressBraceProtection.

But can you explain again why this is a problem in publisher and location? They are literal lists, and if BibDesk doesn't treat location = {{Leiden}} as "a list with one item, that item being Leiden", it's just wrong as far as I can tell.

blip-bloop commented 5 years ago

:robot: this is your friendly neighborhood build bot announcing test build 5.1.60.3604 ("update test cases")

Install in Zotero by downloading test build 5.1.60.3604, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

jdhauck commented 5 years ago

Thank you so much. That works!

As to your question:
If there is only one item in these fields it doesn't matter, true. But for publishers with more than one locations {London and New York} for example, some styles might want to print only the first location, others want all of them, here it's important that the "and" is preserved as list item separator. Hence, I prefer to protect manually those "and"-s that need to be protected.

retorquere commented 5 years ago

Hmm. Well, OK, I'll merge this, but if a good argument against it emerges, I'm reopening the discussion. Since it passes through Zotero, and Zotero has only one location field, London and New York means {London and New York}, not {London} and {New York}

retorquere commented 5 years ago

5.1.62 will be out soon.

jdhauck commented 5 years ago

Great, thank you!

jdhauck commented 5 years ago

... sorry ... I didn't mean to reopen this :/

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.