Toby Cubitt's response
Joris
Hi Joris,
Thanks very much for reporting this bug, and for the minimal example.
Dan's reply is indeed very helpful - it would have taken me quite some
time to figure out this subtle chain of events!
To quote TeX-by-Topic:
Counters 0–9 are scratch registers, like all registers with numbers
0–9. However, counters 0–9 are used for page identification in the
dvi
file [...] so they should be used as scratch registers only inside a
group.
So my understanding was that using counters 0-9 within a group was
safe.
But it seems this isn't quite true.
Dan is incorrect in his statement about \count@consecutive (count
register 0) not actually being needed. It is incremented within
\cref@processconsecutive. But as it's passed to that macro as a
parameter, it's understandable that he missed this. (I guess my
thinking
was that, since \count@consecutive and \count@group are only ever
defined
within a group, it would be poor style to refer to them directly in a
separate macro like \cref@processconsecutive. The latter macro would
then
depend on being called in a context in which these count registers
were
defined, which is a recipe for confusion and bugs. So I instead had
\cref@processconsecutive take an argument specifying the count
register
it should use, even though in cleveref it only ever gets passed
\count@consecutive. The downside is that a textual search in
cleveref.sty
for \count@consecutive will not turn up all uses of that count
register.)
The values 0, 1, 2 and >2 for \count@consecutive are significant in
\@cref, so replacing the count register with conditionals (it would
require 2) would be uglier and wasteful. It's also conceivable that
larger values could become significant in future.
I believe the attached version (which simply replaces all \countdef's
with \newcount's) fixes this issue. At least, it does for me when I
test
your minimal example. Could you test it and let me know if it works
for
you? If so, I'll upload the new version to my web site and then CTAN.
All the best,
Toby
PS: Googling didn't reveal which mailing list / newsgroup you posted
your
original question on, so I couldn't copy this reply there, or thank
Dan
Luecking for his help. Perhaps you could pass on my thanks?
Donald Arseneau
> So my understanding was that using counters 0-9 within a group was
> safe. But it seems this isn't quite true.
The requirement is more strong than just a local group -- you must
ensure that the output routine is not "exercised" while the
redefinitions
are in effect. This could be quite easy! If the macros generate some
text, then simply put \leavevmode before the group. If the output is
not plain text, but might contain \par or \vskip, then you can gather
the
output in a scratch macro or toks register, and output it after ending
the local group.
Donald Arseneau
Toby
> On Nov 26, 6:03 am, Joris <pin...@gmail.com> wrote:
>
> > So my understanding was that using counters 0-9 within a group was
> > safe. But it seems this isn't quite true.
>
> The requirement is more strong than just a local group -- you must
> ensure that the output routine is not "exercised" while the
> redefinitions
> are in effect.
Ah, thanks a lot for clarifying this for me.
> This could be quite easy! If the macros generate some
> text, then simply put \leavevmode before the group.
>
> If the output is
> not plain text, but might contain \par or \vskip, then you can gather
> the
> output in a scratch macro or toks register, and output it after ending
> the local group.
The output is just plain text, and the \leavevmode seems to work!
Thanks to everyone here who's helped with this - in the end, I've not
had to do any work to track down the cause of the bug, I've been
handed a simple one-line fix on a plate, and I've even learnt a bit
more about TeX. What more could I possible ask for?
Toby
Joris
Given that you've produced such a useful package, it's not surprising
people are willing to help out.