Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

Hi Branden,

On Mon Dec 2, 2024 at 12:51 AM CET, G. Branden Robinson wrote:
> At 2024-12-01T23:06:41+0100, onf wrote:
> > I propose the following changes to make their behavior consistent:
> > 
> >  1. `ne` breaks line before breaking the page as `bp` does
> >  2. `ne` does not break line before breaking the page if called with
> >     the no-break control character (which currently doesn't modify
> >     its behavior in any way)
> > 
> > The second point means that the old behavior of .ne can be recovered
> > via 'ne. This matches the behavior of 'bp, which breaks page without
> > breaking the line as well.
>
> I don't agree with this change, because it's not necessary.

No changes to groff are, strictly speaking, necessary.
Your planned changes to .ad aren't necessary by the same logic either.
But you desire them anyway because they make groff's behavior more
reasonable. The same desire has motivated my proposal.

> Formatter requests are primitive things.  Most requests don't also perform
> breaks. Only a handful do. Those that do support the no-break control
> character to _schedule_ a change to formatter state at the next break,
> when that happens for some other reason.

Please tell me how that is the case here:
  $ nroff << EOF | sed -E 's/^/./'
  .pl 3
  .fi
  One two three
  four five six
  'bp
  seven eight nine
  .br
  eleven twelve.
  EOF
output:
  .
  .
  .
  .One two three four five six seven eight nine
  .eleven twelve.
  .

It's obvious here that 'bp breaks page IMMEDIATELY, not when the .br
is issued. The difference between .bp and 'bp is that one also breaks
the pending input line and the other does not, NOT that the latter
schedules page break after next line break.

My proposal seeks to make `ne`'s behavior consistent with that of `bp`.

> [...] There's nothing wrong with or weird about having a `ne`
> request when an output line is pending.

Please explain how, given the following descriptions from groff(7):
  .bp       Break page and start a new one.
  .ne d     Break page if distance to next page location trap is less
            than distance d (default scaling unit v).

is it not reasonable to expect these two lines to behave similarly:
  .ne 3v
  .if \n[.t]u<3v .bp

... because they don't.

> > Note that this change would break compatibility with other troff
> > implementations. However, it would be easy to fix any documents
> > which rely on the current behavior by substituting[2] any .ne
> > for 'ne, which, as pointed out above, behaves exactly like .ne
> > in other troff implementations.
> > 
> > I invite anyone who disagrees with this proposal to raise any
> > objections they might have, either here or on the bug tracker.
>
> I don't exactly object, but I'm pretty deeply uncertain about it.
>
> And we'd need to retain traditional handling of `ne` for AT&T
> compatibility mode, anyway.

The 'anyway' sounds like you think I am suggesting we remove the
current behavior entirely. As I explained in the part you quoted
above, that is not the case. `ne` would still behave as it does
now if called with the no-break control character (i.e. 'ne).

> If you disagree with that, then I _do_ object.

I see no reason to change the behavior in compatibility mode, I just
forgot about it. We can simply add this to the proposal:
  3. `ne` does not break line in compatibility mode

To summarize, `ne` would break line if
  a) in compatibility mode
  b) not in compatibility mode and called with the regular control
     character

~ onf