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
