[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Differences in `ne` and `bp` line-breaking behavior
From: |
G. Branden Robinson |
Subject: |
Re: Differences in `ne` and `bp` line-breaking behavior |
Date: |
Sun, 1 Dec 2024 22:27:03 -0600 |
Hi onf,
At 2024-12-02T04:45:27+0100, onf wrote:
> On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> > > One two three
> > > four five six
> > > 'bp
> > > seven eight nine
[...]
> > > 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.
Then the page break is not immediate.
> 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.
The description of `ne` in groff(7) could be deficient. The document
does try to caution the reader of this:
Request short reference
Not all details of request behavior are outlined here. See the
groff Texinfo manual or, for features new to GNU troff,
groff_diff(7).
I haven't done a brutal red-teaming of these request summaries for a few
reasons.
1. It's a big job.
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.
3. Some day, groff(7) will have sections and subsections corresponding
to more or less every node in chapter 5 of our Texinfo manual, so
the summaries will be less susceptible to being read as the whole
story. Every 12-18 months Larry McVoy shows up to ask why we
haven't rewritten our Texinfo manual using a groff macro package
yet. I've offered an answer, which to date has not elicited an
expression of satisfaction from him: "I'm workin' on it." I observe
that CSTR #54, the gold standard, is characterized in _Unix Text
Processing_, another esteemed text, as "original" and
"authoritative" but also "dense": maybe some gold doesn't glitter.
At any rate, CSTR #54 does little that can't be accomplished in a
man page. Prior to the "Tutorial Examples" section, which is
canonically inappropriate for "reference, not tutorial" man pages,
it employs a footnote only once and multiple columnation not at all.
Consequently, I think it's reasonable to provide groff's equivalent
of CSTR #54 as a man page.
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.
> > [...]
> > > 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.
In situations like these it is often useful to enlist a third party as
mediator/interpreter. Perhaps they can help us find a common language.
> 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
See above. You're giving the deliberately terse description in "Request
short reference" more weight than perhaps it can bear.
> Just a friendly reminder that it was also your "frustrated intuition"
> before you somehow decided that it's not a bug, but a feature.
Sure. Sometimes my frustrated intuitions are resolved by fixing bugs,
and sometimes by improving my understanding.
> > 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?
You did. I recapitulated it for emphasis.
But this does also distinguish it from the `ad` case you deployed
against me, where:
>> Frequently, [`ad`] is used incorrectly. You can tell this because
>> the request is either a no-op where it is used, or has a perverse
>> effect, like frustrating the reader's deconfiguration of adjustment,
>> making some paragraphs in the man page have ragged right margins and
>> the others, not. These are obviously unintentional errors. ...
> 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.
> On the other hand, I must admit I am frustrated by your replies on the
> topic.
Sorry. :(
> 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've been assured that I should have been reading Dale Carnegie instead.
> 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.
> 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.
$ perl -e 'print "hello " x 1325, "\n";' | groff -a | uniq -c
1 <beginning of page>
66 hello hello hello hello hello hello hello hello hello hello hello hello
hello hello hello hello hello hello hello hello
1 <beginning of page>
1 hello hello hello hello hello
It wouldn't surprise me if the latter is the arena in which our
competing intuitions are engaged in combat.
Regards,
Branden
signature.asc
Description: PGP signature
- Differences in `ne` and `bp` line-breaking behavior, onf, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, G. Branden Robinson, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, onf, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, G. Branden Robinson, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, onf, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, onf, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, G. Branden Robinson, 2024/12/02
- Re: Differences in `ne` and `bp` line-breaking behavior,
G. Branden Robinson <=
- Re: Differences in `ne` and `bp` line-breaking behavior, onf, 2024/12/02
- Re: Differences in `ne` and `bp` line-breaking behavior, Dave Kemper, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, G. Branden Robinson, 2024/12/01
- Re: Differences in `ne` and `bp` line-breaking behavior, onf, 2024/12/02
Re: Differences in `ne` and `bp` line-breaking behavior, Deri, 2024/12/02