Follow-up Comment #7, bug #67838 (group groff): Hi Alexis,
At 2025-12-23T05:13:55-0500, Alexis wrote: > Follow-up Comment #5, bug #67838 (group groff): > > Branden, I've reviewed bug #67082 and can confirm that this bug's file > #58003 attachment fixes the "Previoius" node error from "5.20.3 Using > Fractional Type Sizes". My thanks to you and to Dave for the subsequent coalescence of duplicate tickets. > I agree with Dave's comment that "test[ing] all the links in the > manual [is] something worth doing but […] sounds tedious." I'm happy > to volunteer doing that if the following questions can be answered > beforehand: > > * What is groff's the minimum version requirement for texinfo? 5.0. See: https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n105 > * Could the minimum version requirement for texinfo be updated to 7.x if it's > lower? If yes, what would be the possible implications? It _could_, but I'm disinclined to do so unless more recent releases of Texinfo have regressed the contents of groff's Texinfo manual. > * Should the first (sub)subsection omit the previous node declaration, > as it currently is the same as the node's top node I don't know. I don't actually understand--or rather, I don't agree with--the info format's organizational scheme, which appears to encourage the reader to perform a breadth-first traversal of document content. This orientation is contrary to literally thousands of years of practice in human written language. It also makes the writer's job harder, as they can assume even less than usual about whether the reader has absorbed previously presented material. This is why, it seems to me, Texinfo manuals tend to be even more littered with backward references than U.S. legal filings, at least if one is being conscientious. But if, as now seems to be the case, makeinfo's willing to actually diagnose deviations from its, uh, pathbreaking approach to pedagogy, I'm willing to flex, and that's the objective of the now-closed-as-Duplicate bug #67082. > * The manual seems to make inconsistent use of numbered and unnumbered > subsubsections, e.g. "4.6.3 Document Control Settings" has unnumbered > subsubsections, whereas "4.6.5 Body Text" contains numbered > subsubsections. Can all sub*sections be converted to numbered? If not > what is the logic behind numbered vs unnumbered subsubsections? That's a good question. I believe that's an organization I inherited. I can't articulate a principle behind a series of unnumbered (sub)subsections apart from, "if nothing cites the (sub)subsection, it doesn't require numbering". Also, there had been discussion of removing the detailed presentation of the ms macro package from our Texinfo manual in favor of a stub explanation like the other macro packages get, but I've never been able to quite steel myself to do it. Part of me feels that, despite the additional maintenance burden--ms(7) uniquely has to be updated in _three_ places, groff_ms.7.man, ms.ms.in, and groff.texi.in--a concrete presentation of a "full-service" macro package is valuable to ground the reader concretely in the functions that such a package must serve. The next chapter swiftly gets into comprehensive details and minutia such that it's easy to lose one's synoptic perspective (or "ten-thousand-foot view"). So I keep postponing a decision on the matter. The material on character resolution and glyph-to-Unicode mappings, and on the "grout" output format, each are in greater need of my editorial attention. Regards, Branden _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67838> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
