Follow-up Comment #11, bug #67363 (group groff): Hi Ingo,
At 2025-08-04T21:13:03-0400, Ingo Schwarze wrote:
>> How this creates work for you, you'll need to explain to me.
>
> I'm not claiming that this particular commit causes any particular
> problem.
Under such circumstances, rhetoric like:
* "Utter madness",
* "fragile, overengineered, and likely bug ridden code"
* "You are obviously in way over your head"
* "[You] have produced ... a massive amount of regressions"
* "massive amounts of dysfunctionality"
* "I have no idea what users may be suffering"
* "you get a better chance of actually understanding what you are doing"
* "suffer the resulting havoc"
...is, I submit, overheated.
> What i was trying to say is that overengineering in general
I see. Your actual comment #1, referred to specific commits and code
changes, however.
> causes both design oversights and implementation glitches, both of
> which then tend to cause work, and the difficulty of both finding root
> causes and fixing them generally increases with the degree of
> overengineering, too. Not every instance of overengineering causes
> bugs, but the total number of bugs certainly scales (at least
> slightly) more than linearily with the amount of overengineering, so
> it really matters to keep overengineering down as much as possible. I
> certainly do sense overengineering here.
I think there is some irreducible complexity here arising from the facts
of support for adjustment and hyphenation. Avoidance of such complexity
is no doubt why _mandoc_(1) neglects to perform these functions and why
you counseled me to delete their support from _groff_'s man page macro
packages.
That, however, I decline to do, as such removal _would_ be experience a
regression of many *roff users' experience with man pages. (Possibly a
welcome one in some cases, I concede--but not all.)
Given the following constraints:
* man pages support (automatic) hyphenation and adjustment;
* preferences regarding hyphenation and adjustment differ;
* the user's preferences should override the page author's;
* man pages sometimes need to disable hyphenation and/or hyphenation
when formatting particular specimens of text, _irrespective_ of the
page author's or user's preferences regarding hyphenation and
adjustment differ; and
* groff's recommendations to man page authors regarding configuration of
the foregoing must be portable to other *roffs, and if not honored by
them, should at least not seriously degrade the formatted document.
Put differently, the penultimate point means that an "semantic" or
"structural" aspect of text mandates suppression of hyphenation or
adjustment (or both, as in displayed, unfilled code examples), such that
_preferences_ do not have the opportunity to attach.
It is an unfortunate historical fact that, partly because adjustment and
hyphenation are such fundamental typesetting operations, that *roff's
interfaces for their manipulation froze a bit too early, and left their
manipulation awkward at best. These facts are what the "complicated
dance" comments in the patches (now commits) attempt to adumbrate.
If you have specific recommendations regarding more "right-sized"
engineering solutions to the constraint problem above, I will review
them with interest.
"The manual was intended to be typeset; some detail is sacrificed on
terminals." -- "BUGS", man(1), Unix Time-Sharing System Programmer's
Manual, Eighth Edition, Volume 1, 26 February 1985
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67363>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
