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