Follow-up Comment #13, bug #68133 (group groff): Hi John,
At 2026-05-01T11:44:55-0400, John Gardner wrote: > Follow-up Comment #12, bug #68133 (group groff): >> Yes, that's implied by your previous sentence (and a reasonable >> level of diligence in writing documentation). > > Apologies, an entire paragraph is missing from my response; I was > workshopping my response and deleted what I thought was a continuation > of a quote-block. Ah, I see. > The reason I brought up undocumented behaviour in the abstract was > because I wanted to compare how undefined behaviour is documented in > _bash_(1) and the *STANDARDS* sections of other manual pages of > POSIX-sanctioned utilities, but realised those probably aren't the > best examples I could give (mainly after remembering > [https://github.com/koalaman/shellcheck#testimonials this] testimonial > of the ever-popular _shellcheck_(1) utility…) A bit of a barbed observation, but I can't say there isn't _some_ justice to it--troff and the Bourne shell came from the same research lab in the same rough era, and for that matter GNU Bash and GNU roff (as I term it) weren't born all that far apart from a 2026 perspective. The two languages share a lack of a formal grammar and readiness to incorporate new features (in early days) without leaving a documentary record of the design considerations that went into them or how the composition of features was contemplated. [https://archive.org/details/rc-shell/mode/1up Tom Duff's paper presenting his `rc` shell] is a seminal work in my view. Evidently, documenting AT&T troff was a significant challenge; its manual remained an "internal memorandum" only for something like give years after it went into deployment, from 1973 until what we now know as CSTR #54 appeared in 1979 with Seventh Edition. I observe with some dismay that said manual, while dated 1976, emerged into public view only after Ossanna's death in late 1978. It's not hard to imagine that there he would have put further work into it before declaring it "ready", had he been given the chance. In any case, as you probably know, pointing to the "STANDARDS" section of other Unix facilities isn't quite apposite, because *roff is not standardized. That fact presents both opportunity and hazard. > I know nothing I say will change so your mind, I don't think that's a fair comment. I change my mind, get dissuaded, and withdraw my own wild ideas with some regularity. Observe: https://lists.gnu.org/archive/html/groff/2025-01/msg00002.html https://savannah.gnu.org/bugs/?65955 https://savannah.gnu.org/bugs/?65710 https://savannah.gnu.org/bugs/?64354 https://savannah.gnu.org/bugs/?64131 https://savannah.gnu.org/bugs/?62182 https://savannah.gnu.org/bugs/?62296 (counterparty: John Gardner) Sometimes I even talk _myself_ out of stuff. https://savannah.gnu.org/bugs/?64616 https://savannah.gnu.org/bugs/?61422 https://savannah.gnu.org/bugs/?59906 https://savannah.gnu.org/bugs/?59825 If you want to convince me, _be convincing_. * Explain to me how using `tr` as a general rewriter of strings (in the computer science sense) of length one is desirable, and precedented in other _roff_ implementations. Or: * Illustrate how use of `tr` in the foregoing sense is widespread among "practical" users and documents. A pile of well-known man pages that did so would constitute mighty evidence all by itself. > and I'll just have to prepare myself for other unexpected breaking > changes in future Groff releases. "Breaking changes" are the way of nearly all software that is actively developed, because programmers are not possessed of supernatural foresight. Such mere mortal projects, by [https://davidlowryduda.com/another-year-another-texlive/ one account] include the 800-pound gorilla to _groff_'s capuchin monkey. That said, as I observed [https://lists.gnu.org/archive/html/groff/2026-03/msg00039.html before], if you pay attention to announcements of release candidates on the low-traffic [https://lists.gnu.org/archive/html/info-groff/ info-groff] list, you'll know to expect such "unexpected" changes. > The only other thing I'll add is that problematic `.tr` usage should > emit a warning explaining "`o` is attempting to be translated to > non-character `\fB`; a blank space will be added instead". I wont't commit to that phrasing, but I expect to have something in the same ballpark. 1. When not in compatibility mode, emit a warning in category "syntax" and advise that the escape sequence is ignored/discarded/whatever. 2. When in compatibility mode: a. If the transformation is one expected by a "historically significant" document (q.v.), quietly perform it. b. If not, warn and ignore/discard it as in case 1 above. For example, I expect the following: $ printf '.tr A\\f[BI]\n\\[rq]Allo there\n' | ~/groff-1.24.1/bin/groff -ww -a <beginning of page> <rq> llo there $ printf '.tr \\f[BI]Z\nfoo \\f[BI]bar\n' | ~/groff-1.24.1/bin/groff -ww -a <beginning of page> foo bar $ printf '.tr \\f[BI]\\h@1i@\nbaz \\f[BI]qux\n' | ~/groff-1.24.1/bin/groff -ww -a troff:<standard input>:1: error: expected ordinary, special, or indexed character, got a parameterized horizontal motion troff:<standard input>:1: error: cannot perform character translation from a parameterized horizontal motion <beginning of page> baz qux to more closely resemble: $ printf '.tr A\\f[BI]\n\\[rq]Allo there\n' | ~/groff-FUTURE/bin/groff -ww -a <beginning of page> troff:<standard input>:1: warning: cannot translate character to non-character escaped 'f' [-w syntax] <rq>llo there $ printf '.tr \\f[BI]Z\nfoo \\f[BI]bar\n' | ~/groff-FUTURE/bin/groff -ww -a <beginning of page> troff:<standard input>:2: warning: cannot translate non-character escaped 'f' to character [-w syntax] foo bar $ printf '.tr \\f[BI]\\h@1i@\nbaz \\f[BI]qux\n' | ~/groff-FUTURE/bin/groff -ww -a troff:<standard input>:1: warning: cannot translate non-character escaped 'h' to non-character escaped 'h' [-w syntax] <beginning of page> baz qux Not sure about the last case. It seems okay to me to go "full error" when _neither_ participant in the character translation is a character; possibly the user had an entirely different request in mind. Finally, I twig that I should point out again as in comment #6, since I sense an undercurrent of spurious claim that I am trying to prevent _groff_ users from pulling off impressive typographical stunts, that the `char` request enables all sorts of things to be turned into "characters", complete with the `charinfo` discussed in comment #8 and comment #9. That enables some stuff I had not imagined and found truly impressive. https://lists.gnu.org/archive/html/groff/2024-12/msg00085.html By _explicitly creating a character_, you can do things like **assign character flags** to it. https://www.gnu.org/software/groff/manual/groff.html.node/Characters-and-Glyphs.html Given that there is no way to assign character flags to a character except with a _request_--there is no escape sequence that does so--and that manipulable character flags are a GNU _troff_ extension to the *roff language in the first place, I regret to say that objections to this change appear, to me, to have failed to consider long-standing facts about what it means for something to be a "character" in GNU _troff_. In other words, how is one supposed to control the character flags of a character that the `tr` request constructs ad hoc while scanning its input? If I sound unimpressed and underwhelmed by objections to this change, then giving the foregoing some consideration in one's protests might overcome my skepticism. Regards, Branden _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68133> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
