Hi Dave,
> Werner wrote:
> > Reason is that traps are not recursive, IIRC: Traps are not handled
> > while another trap is active (this seems to be missing in the info
> > file).
But they are handled sequentially when a `.sp' passes more than one in a
single bound.
$ cat two.tr
.de trap1
'tm trap 1 \\n(nl
..
.de trap2
'tm trap 2 \\n(nl
..
.wh 1i trap1
.wh 2i trap2
foo
.sp 3i
bar
$
$ groff -zTascii two.tr
trap 1 240
trap 2 480
$
> > In other words, while your first trap is active, it moves down one
> > line, which passes some traps without triggering them.
>
> That bit of information is missing from the manual
And from CSTR 54. Werner, are you sure about that? I don't recall
hearing it before.
Going back to Dave's supplied test, I get two distinct sets of output.
$ fgrep .wh dave.tr
.wh 2.1i trap1
.wh 2.2i trap2
.wh 2.3i trap3
.wh 2.4i trap4
.wh 2.5i trap5
.wh 2.6i trap6
$
$ for t in ps pdf lbp lj4 dvi html ascii; do
> groff -zT$t dave.tr 2>tm.$t
> done
$ sha1sum tm.* | sort -V
4c62d9b9c82522b34895da506a4613d91369acb8 tm.dvi
4c62d9b9c82522b34895da506a4613d91369acb8 tm.lbp
4c62d9b9c82522b34895da506a4613d91369acb8 tm.lj4
4c62d9b9c82522b34895da506a4613d91369acb8 tm.pdf
4c62d9b9c82522b34895da506a4613d91369acb8 tm.ps
549f443a863e83c30705b38208f974ccb0a76fb1 tm.ascii
549f443a863e83c30705b38208f974ccb0a76fb1 tm.html
$
$ cat tm.ps
trap 1
trap 2
trap 4
trap 6
$ cat tm.ascii
trap 2
trap 4
trap 5
trap 6
$
Appending ` \n(nl' to each `.tm' line and repeated runs, commenting
various `.wh' out, and then marking up what's present in the above
output, and what's a duplicate, gives
ps
trap 1 156000 present
trap 2 168000 present
trap 3 168000 same as 2
trap 4 180000 present
trap 5 180000 same as 4
trap 6 192000 present
ascii
trap 1 520 same as 2
trap 2 520 present
trap 3 560 same as 4
trap 4 560 present
trap 5 600 present
trap 6 640 present
It's odd that for `ps' it's the first trap to a rounded position that
springs, but for `ascii' it's the second.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
