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

[onf]

On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> [...]
> >   $ 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
>
> Eh?
>
> If it broke the page "IMMEDIATELY", you'd get this:
>
>     One two three four five six
> <page break>
>     seven eight nine eleven twelve.
> [...]

No, you wouldn't, because that line is still pending.
We seem to interpret the word 'page break' differently.
I interpret it the way it's used in the groff manpage, that is,
as a way of saying "end the page and start a new one". In contrast,
'line break' means "end the line and start a new one". The way `bp`
works is it ends line & page if it's called with a regular control
character, and ends only the page if it's called with the no-break
control character. Given that both of these requests are described
as breaking the page in the manpage, I expect both of them to behave
in the same way.

> [...]
> > It's obvious here that 'bp breaks page IMMEDIATELY,
>
> It doesn't.  It _schedules_ (or enqueues) a page break to occur when the
> next (line) break does, causing the line to be set on the next page.

Um, what?

> As with the phrase "prior to output", you and I seem to have strongly
> divergent interpretations of certain phrases.

Agreed.

> > 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.
>
> This statement is unintelligible to me.  You appear to be contradicting
> the Aristotelian law of identity.

Well, likewise for your statements above.

> > My proposal seeks to make `ne`'s behavior consistent with that of
> > `bp`.
>
> Looking over the request list, why not have `cu` or `ev` imply breaks as
> well?  Or `hy`?  Why not `ft` and `ps`?  What's the limiting principle?

Uh. The limiting principle is that the request's description claims it
breaks the page.
  $ man 7 groff | grep -Ei '^ *\..*break.*page'
  .bp       Break page and start a new one.
  .bp ±N    Break page, starting a new one numbered ±N.
  .ne       Break page if distance to next page location trap is less
  .ne d     Break page if distance to next page location trap is less

> > 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.
>
> Maybe one of the *roff veterans on the list can challenge your
> frustrated intuition here.  I don't seem to be making any headway.

Just a friendly reminder that it was also your "frustrated intuition"
before you somehow decided that it's not a bug, but a feature.

> [...]
> > 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).
>
> The disruptive aspect is that anyone relying on the existing behavior
> (and not rendering in compatibility mode) would have to alter their
> documents to make the appropriate change.

Yes. I think I said that in the first message of this thread?

> That's not forbidden.  We can cross Rubicons.  The "NEWS" file documents
> these.  But a change needs to pay its freight.  As far as I know you're
> the only person in the world who's ever been this upset by the behavior
> of `ne`.  (You can't include me despite my documented confusion with the
> request, because I did not undertake a similar reform immediately
> myself, as I would have if I was certain I was right.  Instead I decided
> I didn't sufficiently understand what was going on with the formatter.
> [...]

I haven't been "this upset" by the behavior of `ne`. I was just puzzled
for a while before I realized it behaves differently than `bp`, which
lead me to file the bug.

On the other hand, I must admit I am frustrated by your replies on the
topic.

> > 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
>
> I'm not convinced.  I reiterate:
>
> "Part of my motivation for reforming/revising adjustment management is
> that I see people mis-applying the existing language feature."
>
> Show me exhibits of people besides yourself making the same mistake with
> `ne`.

When I began using troff, I started with John Ankarstrom's minimalist
Mk macro package[1]. Reading its README.pdf[2] file reveals he thinks
`ne` breaks line (page 4):
  The w macro is an alternative to troff’s ne request, which ensures
  that a given amount of space is available on the page – otherwise,
  a line break is issued – but unlike ne, which takes an exact amount
  of space as its argument, w takes a declarative specification
  describing the amount of desired space in terms of mk environments.

You could argue that it's a typo and he meant to write 'page break'
instead of 'line break'.

In any case, his `w` macro, which he himself describes as an
"alternative to ... ne" which differs only by "tak[ing] a
declarative specification ... of desired space", emulates `ne`
by doing this:
  .  if (\n(_su)>\n(.tu \{\
  .   br
  .   bp
  .  \}

which clearly indicates he expects such a feature to break line
(and doesn't realize .bp does this for him already).

I am sure other instances can be found, but you will have to explain
to me what exactly you mean by the words 'page break' first.

~ onf

[1] http://ankarstrom.se/~john/git/mk/tree/mk
[2] http://ankarstrom.se/~john/git/mk/plain/mk/README.pdf