-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve zref-clever
support
#230
Comments
Can't reproduce the error, using texlive 2023 and updated packages, even without the proposed improvement. |
Hi @muzimuzhi
Thanks for checking. I'm actually relieved, since I find it strange and that "it shouldn't happen". So, better if it's just me. But I'm also running an up to date TeX Live 2023, and just checked I was not getting anything from my
|
Ohhh now I can see the same error. 🥲 I'll dig into this. |
That's what I had meant by "current standing of things". 😉 |
In starred tcb theorem, Related source lines
tcolorbox/tex/latex/tcolorbox/tcolorbox.sty Lines 2167 to 2169 in 67963e2
tcolorbox/tex/latex/tcolorbox/tcolorbox.sty Lines 890 to 912 in 67963e2
With the proposed improvement by @gusbrs,
Therefore the error is never triggered. I'm not familiar with |
Ah, makes sense. It should be tested for emptiness. Thanks for looking into this.
Sounds like a third reason for the suggested improvement. Or "second and a half". ;-) |
The discussion clearly reveals that this is a really an improvement. I see nothing what speaks against it and I will add it to the next Thank you both. |
@T-F-S Once again, thank you very much. @muzimuzhi Thank you too. |
@T-F-S Thank you! |
Hi @T-F-S,
I'm revisiting the support you kindly added for
zref
andzref-clever
(#206), and I think I have an idea for a slight improvement of things.I'd like to suggest using the
reftype
option instead ofcountertype
. I know, it was my own suggestion to do otherwise when we originally discussed this. My argument to make that recommendation then was thatreftype
would apply to any other\zlabel
made within the box's environment, which is true. But I think my reasoning was somewhat skewed because I started from the assumption that the option and the label would (potentially) be done at different places. However, the way you ended up implementing things, these two things are done at the same place:\__tcobox_label_zlabel:n
. Which makes for an easy solution to the problem which made us rule outreftype
, just add a group.I see two advantages of so doing. First,
reftype
is an exact equivalent ofcleveref
's optional argument for\label
. So you no longer have to worry about documentation ambiguities, or slight differences of behavior depending on the "reference backend". Second, it would work forphantomlabel
too, which is currently not covered.The implementation could look like:
A test document for it:
(Btw, that last box, which I added to illustrate the handling of
phantomlabel
in an unnumbered box, throws an ugly error with the current standing of things: "LaTeX Error: Blank key name in key-value input on line 163". I'm not sure why it happens. But anyway, the proposed improvement seems to fix it as well.)WDYT?
The text was updated successfully, but these errors were encountered: