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

[onf]

Hi Branden,

On Mon Dec 2, 2024 at 5:27 AM CET, G. Branden Robinson wrote:
> At 2024-12-02T04:45:27+0100, onf wrote:
> > 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 description of `ne` in groff(7) could be deficient.  The document
> does try to caution the reader of this:
> [...]
>
> I haven't done a brutal red-teaming of these request summaries for a few
> reasons.
> [...]
> 2.  People who love this sort of short [sic] reference tend to love CSTR
>     #54 even more, to the point that some regard it as superior to any
>     groff documentation past, present, and future.  It's impossible to
>     win with that latter subset of people, so we get no suggestions for
>     correction/revision of the man page in that respect.

I happen to not be in that camp. I tend to use manpages as my primary
reference because they fit well with my terminal-focused workflow.
This is no different with groff. When the quality of a groff manpage
is lacking, I turn to other troffs' manpages before looking up other
sources. This is especially true for tbl and eqn, where I usually
consult the respective BSD mandoc manpage first.
(groff's tbl is too wordy and eqn assumes one already knows the
language)

>     [...]
>     Consequently, I think it's reasonable to provide groff's equivalent
>     of CSTR #54 as a man page.

Unfortunately, CSTR #54's description of .ne is merely more terse.
It doesn't explain the topic much better.

> I therefore eagerly solicit your suggestion for how the summary of `ne`
> in groff(7) can be request to accurately document its present behavior.
>
> That's not a substitute for reforming its behavior, but a bug fix for
> the man page in its current form.

Fair enough.

> [...]
> > 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.
>
> You seem to me to be going at the matter pretty gung-ho, from which I
> inferred emotional investment.  I concede that I may be mistaken there.

You aren't mistaken about emotions being present, but about their
source. I generally tend to react this way whenever someone disagrees
with me about something which I perceive as "obviously true".

Granted, these "obviously true" things are often those that have
some emotional value to me, but I am pretty sure I would react
similarly if I was talking to someone and they believed that an
object which I see as red is yellow and I couldn't talk them out
of it.

Our current disagreement has been closer to that last example,
although I can't deny I would be somewhat glad if `ne`'s behavior
changed the way I suggested.

> [...]
> > When I began using troff, I started with John Ankarstrom's minimalist
> > Mk macro package[1].
>
> It is a hazard of reading a lot of Bakunin/Kropotkin/Berkman/Rocker/
> Chomsky that my brain always and without fail reads his surname as
> "Anarkstrom". [...]

I appreciate your taste.

> > 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'm uncertain what he meant.  I'd have to get experience with the
> package, and/or ask him.

Well, I've been using the package for a while now. (Technically
a heavily expanded and modified version I've gradually created.)
He uses `w` in the definitions of headings (`h`) and subheadings
(`s`) to ensure there is enough vertical space for the (sub)heading
and at least a single line of text after it:
  .w h p
where `w` = 'want space', `h` = 'heading', `p` = paragraph,
i.e. want enough space to fit a single line of heading and single
line of a paragraph.

I notice all the instances of `w` are preceded by `br`, but that is
probably because they are followed by an environment switch (`@e`).
`w` breaks line (and page) only if there is not enough space, so
that if there is enough, it would not break a pending input line
before the environment switch, thus making it appear only after the
(sub)heading.

> > 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.
>
> Here's an operational definition:
>
> A troff request or escape sequence that results in a 'p' command being
> produced in troff output.
>
> But that's an _incomplete_ definition, because one can cause the
> emission of a 'p' command without issuing any requests or escape
> sequences at all. [...]

I think the other branch of this thread will be a better place to
attempt defining these words; I will reply there.

~ onf