[bug #56499] adjacent trap behavior undocumented and probably undesirable

[Dave]

URL:
  <https://savannah.gnu.org/bugs/?56499>

                 Summary: adjacent trap behavior undocumented and probably
undesirable
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Sat 15 Jun 2019 05:54:01 AM CDT
                Category: Core
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

$ groff -a << EOF
.de trap1
.tm trap 1
..
.de trap2
.tm trap 2
..
.de trap3
.tm trap 3
..
.de trap4
.tm trap 4
..
.de trap5
.tm trap 5
..
.de trap6
.tm trap 6
..
.wh 2.1i trap1
.wh 2.2i trap2
.wh 2.3i trap3
.wh 2.4i trap4
.wh 2.5i trap5
.wh 2.6i trap6
.nf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
EOF

The above command produces the following (a mix of stdout and stderr):

1
2
3
4
5
6
7
8
9
10
11
12
13
trap 1
14
trap 2
15
trap 4
16
trap 6
17
18
19
20

In a response on the email list
(http://lists.gnu.org/archive/html/groff/2018-06/msg00013.html, which also
addresses an unrelated issue), Werner writes, "[W]hile your first trap is
active, it moves down one line, which passes some traps without triggering
them."  But this behavior is not only undocumented, but seemingly unwarranted:
Nothing in these traps should cause vertical movement.

Neither groff nor CSTR 54 (as Ralph points out in
http://lists.gnu.org/archive/html/groff/2018-06/msg00017.html) documents this
behavior.  But the behavior is not limited to the GNU troff implementation;
Heirloom (http://lists.gnu.org/archive/html/groff/2018-10/msg00008.html) and
Plan 9 (http://lists.gnu.org/archive/html/groff/2018-10/msg00012.html) troffs
also exhibit a version of the bug.  However, Heirloom's results are different
from groff's, implying that groff is not precisely reproducing historical
behavior.  And there seems to be no rationale for the behavior anyway.

Furthermore, it inhibits useful functionality.  One of the above links
describes a use case (for PostScript output) that the current behavior
hinders: "I [was] 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."




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56499>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/