Hi onf, At 2024-12-02T02:14:56+0100, onf wrote: > No changes to groff are, strictly speaking, necessary. > Your planned changes to .ad aren't necessary by the same logic either. > But you desire them anyway because they make groff's behavior more > reasonable. The same desire has motivated my proposal.
You omit part of the logic. I see `ad` _actually get used_. In man pages. Frequently, it 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.[1] I've submitted patches to projects like ncurses and bash (that got accepted, possibly because I included explanations) to correct the misuse. So part of my motivation for reforming/revising adjustment management is that I _see_ people mis-applying the existing language feature. They don't get it. When enough people don't get it, that suggests that the problem is more with the language than with its users. By contrast, your sample size for `ne` misuse is one--yourself. Formerly two, before I came to understand the request. Moreover, I don't think `ne` will ever see uptake among man page authors--for a couple of good reasons. One is that man pages are rendered at widely disparate line lengths. Also, there are subtle annoyances involving changes in line height due to headings being set a larger type size (but only in troff mode), and the height of tables (horizontal rules and horizontal box edges in tbl(1) each take up an additional vee, but only in nroff mode) Much of the time, a guess one makes about how many vees are needed to avoid stranded lines in a man page is going to be wrong. Further, many man page authors care only about terminal output, and accustomed to "continuous rendering"[2] where the problem of stranded lines never rears its head in the first place. I don't think most man page authors are going to develop motivation to exercise this feature whether it behaves as you want, or not. And that's okay, because a superior solution IMO is to (1) support keeps, which I think can be done straightforwardly and adopted without much effort or subtlety of understanding by man page authors and (2) more ambitiously, reëngineer our man(7) (and mdoc(7)?) paragraphing macros under the hood to automatically format paragraphs into a diversion, and avoid stranded lines with internal logic. This will pay big rewards--the document author won't even need to think about it[3]--but will require some cleverness in implementation. Doug McIlroy put me on the scent of one approach, "self-renewing input traps", but I haven't set aside the time to explore this, nor seen it done by anyone else (a foreboding sign). But, those things are for groff 1.25 at the earliest. Though if (1) is as easy as I think it is, maybe I could still get it in for 1.24... > > Formatter requests are primitive things. Most requests don't also > > perform breaks. Only a handful do. Those that do support the > > no-break control character to _schedule_ a change to formatter state > > at the next break, when that happens for some other reason. > > Please tell me how that is the case here: > $ 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. But don't take my word for it. Ask "groff -a". $ printf 'Hello, world!\n.bp\n.c2 @\none two three\nfour five six\n@bp\nseven eight nine\n.br\nten eleven twelve\n' | groff -a <beginning of page> Hello, world! <beginning of page> <beginning of page> one two three four five six seven eight nine ten eleven twelve Now let's try it with the regular control character. $ printf 'Hello, world!\n.bp\none two three\nfour five six\n.bp\nseven eight nine\n.br\nten eleven twelve\n' | groff -a <beginning of page> Hello, world! <beginning of page> one two three four five six <beginning of page> seven eight nine ten eleven twelve > 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. As with the phrase "prior to output", you and I seem to have strongly divergent interpretations of certain phrases. > 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. The `bp` request, regardless of one's choice of control character, _always_ schedules a page break at the next line break. Invoked with the ordinary control character, it also _causes_ a break, and the rest follows as a consequence. > 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? > 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. > > > Note that this change would break compatibility with other troff > > > implementations. However, it would be easy to fix any documents > > > which rely on the current behavior by substituting[2] any .ne > > > for 'ne, which, as pointed out above, behaves exactly like .ne > > > in other troff implementations. > > > > > > I invite anyone who disagrees with this proposal to raise any > > > objections they might have, either here or on the bug tracker. > > > > I don't exactly object, but I'm pretty deeply uncertain about it. > > > > And we'd need to retain traditional handling of `ne` for AT&T > > compatibility mode, anyway. > > The 'anyway' sounds like you think I am suggesting we remove the > current behavior entirely. You're reading a lot into the word "anyway". In this context it is synonymous with "besides", or "in any {event,case}". Please dial back your attempts at mind-reading. > 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. 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. And that was true: when I first started trying to solve stranded line problems in groff's corpus of man pages, this issue was entangled with the changed-type-size-impact-on- line-height and non-zero-height-of- horizontal-rules-in-nroff-mode issues I mentioned above.) > 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`. Regards, Branden [1] Man page authors are notorious cargo cultists. Here's one of my favorite examples. https://lists.gnu.org/archive/html/groff/2019-03/msg00032.html John Gardner's hypothesis is the best I've seen for that case. [2] since groff 1.17, 3 May 2001, thanks to Werner Lemberg [3] I predict that some would mis-describe this behavior as "implementing the Knuth-Plass paragraphing algorithm", because it's a lot easier to tell that K-P doesn't strand single lines of a multi-line paragraph than it is to tell that it adjusts interword spacing in an esthetically superior way. In fact, that would be a great way to measure this frequently voiced complaint about groff, except for the facts that (1) most people who voice such complaints about groff simply repeat things they've heard or read, rather than testing the claim for themselves and (2) most people who have voiced such complaints in the past, never stop making them even after the underlying problem is fixed, no matter how much time passes. Unix has always had a cadre of users who resemble sports fans much more than scientists or engineers, to the nonstop detriment of its culture.
signature.asc
Description: PGP signature