On Tue, Mar 17, 2026 at 10:11 PM G. Branden Robinson <[email protected]> wrote: > You might not be using "coupling" in a sense with which I'm familiar.[2]
Yes, sorry, I was using it in an informal sense: currently hyphenation language and mode live in different scopes, and the proposal is to put them in the same scope, thus (informally) "coupling" them more than they currently are. Perhaps not the best word choice. > Again, this could be a matter of my deafness, but I'm having trouble > hearing any justification for keeping the hyphenation language global > that doesn't amount to "because it's always been that way". True, behind my post were some unstated assumptions, so let me state those as a framework. 1. Adding hyphenation language to the environment falls into the space along the continuum between the definitions of "gratuitous change" and "improvement" to which you and Ingo largely agreed (http://lists.gnu.org/r/groff/2026-02/msg00067.html). 2. In Ingo's words (to which you agreed with a caveat[1]): "Obviously, edge cases exist... between gratuitous changes and improvements.... The way to deal with edge cases is to build consensus and only change behaviour when consensus is reached." This framework gives the existing behavior substantially more weight. If we were discussing _designing_ a language, I'd fully agree with your principle to make as few things global as practical. But we're discussing _modifying_ a language aspect that has been in place for 33 years.[2] Unfortunately, only three people have voiced opinions on this topic, but with one person championing the change and two tepidly opposed to it, I'm not sure either side can be said to have mustered consensus, which by the above principles argues against making the change. One more thing worth pointing out: under this proposal, creating a new environment without copying another environment's configuration leaves one field of the new environment (hyphenation language) undefined. That's unprecedented in the history of *roff environments: every environmental parameter has heretofore had a meaningful initial value. The auxiliary proposals to ease copying another environment upon new-environment creation are designed to paper over this wart, but the wart still exists when using the default environment-creation mechanism. That should also give one pause. [1] The nature of your caveat is unclear to me, because it states a (fairly uncontroversial) principle but fails, at least to my reading, to tie this principle back to Ingo's point. So whether this caveat is relevant to the current debate, I'm unsure. [2] Per NEWS, the .hla request was introduced in groff 1.07, dating to around March 1993.
