[bug #57538] [me] incorrect computation of space `ne`eded by `(b` blocks

[G. Branden Robinson]

Follow-up Comment #11, bug #57538 (project groff):

[comment #9 comment #9:]
> Thanks for tracking down this mewling kitten, Branden!
> 
> The original longstanding bug (as the opening comment here observes, it was
first reported to bug-groff in 2012)

...and the line of code I changed was present at the Big Bang, authored by the
demiurge James Clark himself, apparently.  I can't lay this one at George
Helffrich's doorstep.  :)

> made me long ago excise .(b/.)b from my own -me documents.

That should not be necessary--you should be able to pick it back up now.
 
> But why should .ne's parameter need to be adjusted so?  The
diversion-adds-an-extra-line-feed explanation only takes you so far, since
using .ne in place of the .(b/.)b pair in the original example -- which,
absent those two -me macros, does not use a diversion -- still results in a
premature page break when the seven-line block would fit on the last seven
lines of the page.

Hmm, I guess I did not share my experiments with a raw roff document.  I
thought I had.

As far as my mental model of the formatter goes, the .ne request works as I
expect.

Try this rofflet.


$ cat EXPERIMENTS/count-lines.roff 
.de XX
.  br
.  nop \\$1\c
.  nr N \\$1-1
.  if \\nN .XX \\nN
..
.nf
.ne \nNv
.XX \nN


(U.S. letter paper is assumed here.)

Call it like this (groff 1.22.4 is fine, and, I suspect, _any_ groff before
that).


$ nroff -rN66 EXPERIMENTS/count-lines.roff


You will notice that no extraneous blank lines are output.  We're exactly
filling the 66-line virtual page height.

Change 66 to 67 and you'll see something else happen.

This example can of course be made simpler, deparameterized, more
straightforward, and longer, with the help of the `seq` command (or laborious
typing).  Here is one equivalent.


.nf
1
2
3
.\" yadda
64
65
66\c


The above _also_ does not produce extraneous lines, but take off that last
`\c` and it will.

That is because the newline at the end of the file is read, interpreted as a
word break, and causes a downward vertical motion (guaranteed with filling
disabled, conditional otherwise).  But we're already at the bottom-of-page
double-secret-probation page location trap, so the page is ejected and a new
one begun.

As I understand it, .ne takes us only as far as we need to go--literally!

I will admit that diversions make this issue more difficult to deal with. 
When adding them to the mix, things get more complicated because of the
"partially collected line" business.  When diverting, I couldn't use `\c`
anymore and I had to use groff's `chop` request to get the final newline/break
out of the diversion.  BSD me(7), given its original date of authorship, could
not avail itself of that facility.


$ cat EXPERIMENTS/divert-lines-param.roff 
.de XX
.  nop \\$1
.  nr N \\$1-1
.  if \\nN .XX \\nN
..
.di YY
.nf
.XX \nN
.di
.chop YY
.YY


(You can add a `ne .\nNv` request before outputting the diversion `YY`--it
makes no difference because the diversion fits a page--_if_ its last break is
removed.)

> That makes this fix feel more like a workaround to the underlying problem,
which is that .ne "grabs" more space than necessary.  And the thread linked in
comment #1 suggests this problem isn't limited to the -me package.

I'll look at that thread but I think my examples above establish that it
doesn't, and it works the same in troff and nroff modes.
 
> That is, while I originally reported this problem in -me's .)b macro, I'm
beginning to think the underlying problem is with .ne itself.

Please play with the foregoing and see if you still feel that way.  If you
don't, please supply some example pure roff input that seems to misbehave, and
we can start a new ticket against the core.  :)

    _______________________________________________________

Reply to this item at:

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

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