>> Can you please adjust my `R' file to trigger the bug or problem?
>
> Use a line length of 1.6 inches.
Thanks.
> By the way: instead of \h'0' you can also use \v'0', \X'', or
> probably a lot of other things that put "something else" in the
> output.
Exactly. After some debugging I now wonder whether this is a bug at
all but rather a consequence of how \R is implemented. An
explanation:
If you have this input
.ll 1.6i
.
aaa bbb ccc ddd eee fff ggg hhh\R':c \n[.k]'
there will be eventually a line break after `ggg'. However, after
processing the space after `ggg', the line is not overfull yet, so
troff continues to collect input until it sees the space (or in this
case, the newline) after `hhh'. At this point, the input line is
longer than the line length, and the line gets broken.
If you say
aaa bbb ccc ddd eee fff ggg hhh
.nr :c \n[.k]
there has been a space right before the `.nr', so troff triggers a
check whether we have an overfull line, breaks the line, and the
value of \n[.k] is always correct.
On the other hand, the \R escape sequence works completely
transparent, this is, it leaves no traces that it has been called at
all. In other words, at the point \R is processed, the check for
the overfull line hasn't been done yet and you get a value for
\n[.k] which is even greater than the current line length.
In my opinion, it's best not to change the whole issue but to add a
warning in the documentation that you need \h'0' or something similar
in front of \R so that \n[.k] is correct within \R.
BTW, other registers like \n[.ll] are affected similarly.
Opinions?
Werner
