Follow-up Comment #41, bug #64360 (group groff): [comment #38 comment #38:] > Examining grout files is very useful in debugging, including > comparing grout between versions to see what has changed.
There are myriad ways to produce the same visual output with wildly different grout. The grout produced by groff's formatter may have been fairly stable for the duration of the time you've been working on gropdf, but to my knowledge there is no requirement that it remain so. For instance, it currently emits "t" grout commands, but if a future release needs to prioritize *rout cross-compatibility, it would need to eliminate "t" (a groff extension) from its output. This would drastically alter grout, in a manner completely on spec, without changing the final page layout. This is an extreme example, but there are certainly smaller ways grout might in the future be altered or optimized without altering the final page, and none of this is forbidden by any specs I know of. On the contrary, the manual even contemplates such a thing, saying in a couple places in the grout chapter, "GNU 'troff' does not produce such values, but 'groff''s output driver library handles them." Such changes might inconvenience the small number of users who read grout directly, but Branden's proposed changes are also designed for the convenience of those users, so I don't think citing inconvenience alone gets you very far. > I am unable to find a "feature change" ticket which > proposes to alter current grout format Bug #63544 proposes it. > I don't find the added white space particularly helpful in > aiding comprehension, perhaps because I have been gazing at > grout for longer than Branden. Being a domain expert does sometimes blind one to difficulties newcomers face. But the overwhelming trend in software development over the decades has been of code readability taking priority over making code terse or clever. Code, even (and maybe especially) code generated by software, should strive to become more accessible, to lower the barriers to entry for future developers. > I could write a little script which removed the white space to > satisfy my "gout". Yes, this is the aspect that makes me wonder why there is such hue and cry over this change. > Except that if the format of grout is altered it means that > grout before the change cannot directly be compared with the > new version, it would require an extra step to reformat one of > the versions. But the extra step, as you point out, amounts to a one-line perl script. This hardly seems insurmountable for the minuscule number of people who do such things. > I think this falls under Ingo's definition of a "gratuitious > change" (see > <https://lists.gnu.org/archive/html/groff/2026-02/msg00030.html>). > In that possibly the only person, out of regular grout > readers, who would find this beneficial, is Branden himself, I would like to envision a future where expertise of groff internals is not confined to one person. Making code (both source code and code generated by it) easier to read makes such a future more plausible. Branden's commit logs are littered with sentences like "change function name 'zlorp' to 'initialize_character_translation_array'." One could argue that such a change currently only benefits him, but the simple rebuttal is that it also makes the code much more maintainable over the long term by both Branden and non-Brandens. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64360> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
