groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] page location traps


From: Dave Kemper
Subject: Re: [groff] page location traps
Date: Wed, 24 Oct 2018 17:28:54 -0500

On 6/16/18, Ralph Corderoy <address@hidden> 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]