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

[G. Branden Robinson]

Hi onf,

At 2024-12-01T23:06:41+0100, onf wrote:
> I have discovered recently that `ne` and `bp` behave differently in
> regards to pending input lines. `bp` breaks such lines, while `ne`
> does not. In practice this means that `ne` does not behave like a
> conditional `bp` as one would reasonably expect. This issue has been
> discussed extensively on groff's bug tracker.[1]
> 
> 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.  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.

With `ne` in particular, this was a point I had to learn when getting
windows and orphans under control in groff's man pages.  But after a
little while, the light came on.  I added a caveat to our Texinfo manual
about it:

     This method is reliable only if no output line is pending when 'ne'
     is invoked.  When macro packages are used, this is often not the
     case: their paragraphing macros perform the break.  You may need to
     experiment with placing the 'ne' after the paragraphing macro, or
     'br' and 'ne' before it.

...but I now think I can recast that.  There's nothing wrong with or
weird about having a `ne` request when an output line is pending.

> 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.  If you disagree with that, then I _do_
object.

> [1] https://savannah.gnu.org/bugs/?66447

Regards,
Branden

signature.asc
Description: PGP signature