On 27-Jun-10 19:39:54, Anton Shepelev wrote: > Hello all, > I think, although it is not explicitly documented, > it is inferrable from the desctiprion of the \n > escape: > > Interpolate number register with name IDENT > (one-character name I, two-character name ID). > This means that the value of the register is > expanded in-place while gtroff is parsing the > input line. Nested assignments (also called > indirect assignments) are possible. > > [Then some examples follow which it might be > useful to supplement with a sample of the dis- > cussed behaviour...]
Yes, that description does imply this behaviour (or at least suggests it ... )! I have also gone back to some old printed UNIX documentation which I have, and in the 1976 "Nroff/Troff User's Manual -- Reference Manual", section 8, it is stated: "... a number register cab be ... interpolated into the input in a variety of formats." and, later: "When interpolated, a number register is converted into decimal (default), decimal with leading zeros, lower-case Roman, upper-case Roman, lower- case sequential alphabetic, or upper-case sequential alphabetic, according to the format specified by 'af'." Now that certainly implies that the register is read out as characters, at any rate when it is being interpolated into text material. I think where the obscurity or confusion may arise is that one might expect that when used in a numerical context (e.g. ".nr X \nY") its numerical value would be used. However, once one realises that when troff encounters a line like ".nr X \nY" it is reading input, and therefore will (presumably ... ) extract the contents of Y as characters, even if the number in Y is being stored as a binary integer. The following seems to confirm this: nroff << EOT > .nr X 9 > .nr Y (8-9) > .af Y I \"UC Roman > The value of Y is \nY > .br > .nr X \nY > The value of X is \nX > EOT <standard input>:6: warning: numeric expression expected (got `I') The value of Y is -I The value of X is 9 So '\nY' was output both into the text, and also into ".nr X \nY", as "-I", using the upper-case Roman format (and the value of \nX was not changed). > Now that the reader knows that \n performs textual > expantion, it is logical how the assgnment of a neg- > ative value can turn into a decrement. > > My humble opinion is that such behaviour is asymmet- > rical (decrement for negative values, but assignment > for positive ones) and not evident form the first > sight, and that it could be changed by delegating > the increment/decrement operation to a separate > request (like .ir). That -- the asymmetry -- is also my feeling exactly! However, I think the increment/decrement operation is best left alone! Consider: nroff << EOT > .nr X 9 > .nr Y (-1) > .nr X \nY > The value of X is \nX > .br > .nr X +\nY > The value of X is \nX > .br > .nr Y 10 > .nr X +\nY > The value of X is \nX > EOT The value of X is 8 The value of X is 7 The value of X is 17 So, provided the "\nY" is preceded by "+" as in ".nr X +\nY", the increment will take place appropriately whatever the sign of \nY -- a decrement if the sign is negative. So, if you want to use \nY in this increment/decrement way, you can use the "+" prefix. And, of course, if you do not want an "accidental" decrement in an assignment, when \nY is negative, you can bracket it: ".nr X (\nY)". And, while you're at it, you might as well always bracket it since the "+" prefix will still work as before with the brackets, if that's what you want to do: nroff << EOT > .nr X 9 > .nr Y (8-9) > .nr X +(\nY) > The value of X is \nX > EOT The value of X is 8 and assignments ".nr X (\nY)" will always be safe. > Yes, this will render all existing sources incompat- > ible and require their authors to replace all decre- > ments and increments with the new escape :P > > Anton Lovely! Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.hard...@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 27-Jun-10 Time: 23:07:05 ------------------------------ XFMail ------------------------------
