[bug #63777] [me] .in request invokes .$H macro

[G. Branden Robinson]

Update of bug #63777 (project groff):

                Category:                Macro me => Core                   
                  Status:                    None => Need Info              
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up Comment #1:

Hi Dave,

[comment #0 original submission:]
> This happens in a recent groff build a little older than rc2 but with the
latest -me macros.  But the behavior is identical with a stock 1.22.4 build.
> 
> $ cat test.me
> .mso e.tmac
> .
> .de $H   \" user-defined -me header macro
> .tm nn is \\n(nn
> ..
> .
> .vs 2i
> .
> .nr nn 4
> Hello.
> $ groff -ww test.me > /dev/null
> nn is 4
> $ sed s/vs/in/ test.me | groff -ww > /dev/null
> nn is troff:<standard input>:7: warning: register 'nn' not defined
> 0
> 
> Nothing that I can see about setting the indentation level ought to cause
-me to think "starting a new page!"
> 
> Ironically, the -me manual specifies .in but _not_ .vs as a safe low-level
request.

I can contrive a reproducer in raw roff.


$ cat EXPERIMENTS/kemper-header.roff 
.de $H   \" custom page heading macro
.tm nn is \\n(nn.
..
.
.wh 0 $H
.if r XX \{\
.  ie \n(XX .vs 2i
.  el       .in 2i
.\}
.
.nr nn 4
Hello.
.pl \n(nlu


I think what is happening here is that the `vs` request doesn't put anything
on the output--it simply alters the environment.  The vertical position
therefore does not increase above "-1" (the magic  amid-page-ejection value)
until later, when "Hello." is formatted and the `nn` register has been
defined.

`in` puts a break on the output, and therefore the vertical position passes 0,
springing the trap.

Quoting our Texinfo manual:


5.9 Manipulating Filling and Adjustment
=======================================

A break interrupts filling.  Various ways of causing breaks were shown
in *note Breaking::.  The 'br' request likewise causes a break.  A break
is implied by several other requests: 'bp', 'ce', 'cf', 'fi', 'fl',
'in', 'nf', 'rj', 'sp', 'ti', and 'trf'.  If the no-break control
character is used with any of these requests, GNU 'troff' suppresses the
break; instead the requested operation takes effect at the next break.
''br' does nothing.


I therefore hypothesize that using the no-break control character with `in`
will suppress the warning.


$ cat EXPERIMENTS/kemper-header2.roff
.de $H   \" custom page heading macro
.tm nn is \\n(nn.
..
.
.wh 0 $H
.if r XX \{\
.  ie \n(XX .vs 2i
.  el       'in 2i
.\}
.
.nr nn 4
Hello.
.pl \n(nlu


...and so it appears.

I therefore believe the system is working as documented.

What do you think?


    _______________________________________________________

Reply to this item at:

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

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