Re: [Groff] MM's nested lists: AL inside BVL

[Ted Harding]

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) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 24-Jun-10                                       Time: 13:54:53
------------------------------ XFMail ------------------------------