On 6/16/18, Ralph Corderoy <ra...@inputplus.co.uk> wrote: >> Werner wrote: >> > 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.
I finally installed Heirloom troff and ran my test file from upthread (archived at http://lists.gnu.org/archive/html/groff/2018-06/msg00012.html) on it, to inconclusive results. (The Heirloom tests were all run with the -x command-line switch, to allow identifiers longer than two characters, which my example code used.) The stderr output of troff is the same in both groff and Heirloom's implementations, showing traps 1, 2, 4, and 6 were triggered. However, the nroff stderr output is unaccountably different: groff's implementation triggers traps 2, 4, 5, and 6, while Heirloom's triggers 1, 3, 4, and 6. Since this behavior is (1) undocumented, (2) inconsistent across historic roffs, and (3) arguably undesirable, is it accurate to call it a bug and open a bug report on it? To elaborate on point (3): I encountered this while trying to place a trap that gets triggered at the end of the current output line (that is, the next time the output's vertical position is advanced). I did this by placing the trap a single basic unit below the current vertical position, which works in the general case. However, if the output line in question happens to be the last line of the page, this new trap causes groff to skip the generic end-of-page trap, even though it's not overwriting that trap's page position. I don't want to break back compatibility, but I can't envision what use cases would rely on the current idiosyncratic behavior. The current behavior does, however, prevent an elegant general-case solution to what I'm trying to achieve, requiring an ugly workaround. Is there any downside to fixing this bug?
