[bug #63777] break before output has begun invokes top-of-page trap

[Dave]

Update of bug #63777 (project groff):

                Severity:              3 - Normal => 2 - Minor              
              Item Group:     Incorrect behaviour => Documentation          
                 Summary: [me] .in request invokes .$H macro => break before
output has begun invokes top-of-page trap

    _______________________________________________________

Follow-up Comment #2:

[comment #1 comment #1:]
> `in` puts a break on the output, and therefore the vertical
> position passes 0, springing the trap.

Empirical evidence suggests this is indeed what's happening.  And, armed with
a little more knowledge, I find it's documented in CSTR #54 (1992), whose
section 3 states, "A pseudo-page transition onto the first page occurs... when
the first _break_ occurs."  Section 3 is "Page control," and this sentence is
the third one of the section, so this information is fairly prominent.  (And
sure enough, your raw-roff example works the same on Heirloom troff.)

But I'm not sure this behavior is implied by the Texinfo documentation.  The
passage you quoted contains only one sentence on what a break _is_: "A break
interrupts filling."  But there is no pending output, so nothing to be
interrupted, so causing a break at this point logically seems like a no-op,
absent information otherwise.

The Texinfo manual nowhere uses the CSTR #54 term "pseudo-page transition." 
The text about the nl register refers to a "first page transition," but this
term is neither defined nor used anywhere else in the document; in particular,
that a break triggers it is not revealed.  (Side note: this nl paragraph is
missing an end parenthesis that makes the sentence tricky to parse.)

The .output request alludes to the behavior when it says, "This request can't
be used before the first page has started--if you get an error, simply insert
'.br' before the 'output' request."  But this is not a place a user trying to
figure out an interaction between .in and a trap would think to look, and even
then only documents the general behavior in a sideways manner.

So unless I'm overlooking something in the manual (possible: I'm using likely
search terms, not reading the document top to bottom), a statement to the
effect of the one from CSTR #54 would make this clearer.


    _______________________________________________________

Reply to this item at:

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

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