Re: bug: \} in .nr

[Werner LEMBERG]

> If an .nr directive appears as the last line of a brace-enclosed
> .if, .ie, or .el block, and if the closing \} appears on the same
> line as the .nr directive, GNU troff with warnings enabled
> incorrectly complains about "`\}' where number expected".

Thanks for the report.  This affects all requests which can have
optional numerical parameters, e.g. `.ps'.  I don't know when I find
some time to fix this.

> A workaround is to explicitly specify an autoincrement value for the
> number register.  Obviously the bug is that the readahead function
> which the .nr directive calls to discover if it's been given its
> optional third argument is not properly interlocked with \{ \}
> scanning.

Actually, groff ignores `\}' completely if not skipping a block in
`.if', `.ie', or `.el' (the only exception is for scanning numbers,
emitting the above warning message).  In particular, unbalanced
closing braces are not checked.  For example, you can write

  .nr a 1 0 \}\}\}\}\}\}

without getting a warning.  Only the `.while' request checks the
nesting level.

> Other workarounds are to end the \{ \} block with something other
> than an .nr request, or to place the \} on a line by itself (though
> of course this can lead to spurious output).

Placing `\}' on a line by itself is not a good solution.  I recommend
the following:

  .if 1 \{\
  .  nr a 1 0
  .\}

Do it like this, no side effect happens.


    Werner