On 24-Jun-10 11:49:00, Werner LEMBERG wrote: >> My fix was to use round brackets: >> >> .nr \$2 (\*[misc*pop]) > > I've looked into other places in the code, and since Jörgen has used > the `0' prefix, I did the same for consistency. > Werner
I think it is important for people to be aware of the implicit trap with negative-valued numbers. This is hinted at in 'info groff' under * Request Index:: ==> * nr: Setting Registers. but it is not fully explicit. When you write input: .nr X 10 .nr Y 10 .nr Z (-1) \"# So that it is stored as -1 .nr X -1 \"# Now X = 9 you get what you expect, because the "unprotected" '-' is (as stated in info) a "decrement operator", just as in .nr Y +1 \"# Now Y = 11 the "unprotected" + is an increment operator. However, with .nr X 10 .nr Y 10 .nr Z (-1) \"# So that it is stored as -1 .nr Y \n[Z] \"# Now Y = 9 so that in reading ".nr Y \n[Z]" troff has picked up the (now implicit) '-' in '\n[Z]' as a decrement operator. It is, therefore, as though the value -1 of register Z were stored as the string "-1", i.e. as the string in its definition, and the request .nr Y \n[Z] were read as though it had been written (input) as .nr Y -1 However, the opposite does not hold. Starting from scratch (so that no registers have previously been defined) .nr Y 10 .nr Z +1 .nr Y \n[Z] \"# Now Y = 1 so that is not the mechanism! In the "+" case, the value of Z is assigned to Y. It is the same if Z is calculated in an expression to have a negative value. Again starting from scratch: .nr Y 10 .nr Z (7-8) .nr Y \n[Z] \"# Now Y = 9 Hence the trap: If a number register Z has a negative value, then attempting to assign its value to another register *in the way written just above* will decrement that other register, not assign the value of Z to it. On the other hand, if Z has a non-negative value, then this value will be assigned. This trap can be avoided, as is stated in 'info', by *always* enclosing an expression to be assigned in brackets: .nr Y 10 .nr Z (7-8) .nr Y (\n[Z]) \"# Now Y = -1 (and this is always a good idea with numerical expressions in troff, by the way). I am intrigued by this behaviour, by the way. I consider it to be a close approximation to a bug! I have looked into the classic documentation of UNIX troff, and I have not found any warnings about this. These days, I do not have access to a UNIX (non-groff) troff, so cannot test it. So, for anyone with access to UNIX troff, of to Heirloom trogg, what is the behavious on these? Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.hard...@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 24-Jun-10 Time: 13:54:53 ------------------------------ XFMail ------------------------------
