Hi Dave, Your message feels more straightforward to reply to than Peter's, so I'll unfairly deal with yours first.
At 2026-03-17T21:07:13-0500, Dave Kemper wrote: > On Sun, Mar 15, 2026 at 8:52 PM G. Branden Robinson > <[email protected]> wrote: > > I remain convinced that the hyphenation language should be a > > property of the environment, rather than golbal, because the > > hyphenation "mode" that determines the acceptable locations within a > > word for hyphenation breaking is already environmental _and_ the > > hyphenation mode is only intelligible when the hyphenation language > > is known. > > Most hyphenation languages have multiple hyphenation modes that are > compatible with them. Likewise, most hyphenation modes have multiple > hyphenation languages that they're valid with. I'm with you so far... > This many-to-many relationship doesn't lend itself to the tight > coupling that you're asserting. ...but you completely lose me here. I'm not proposing any tighter a coupling than already exists, which is minimal or nonexistent. Nothing in GNU troff imposes any constraints on hyphenation mode selection by hyphenation language selection (even if it probably should, as I think Werner pointed out many years ago[1]). A user can vary both ad libitum and nothing about my proposal changes that. You might not be using "coupling" in a sense with which I'm familiar.[2] > As Peter points out, there are good reasons to have differing > hyphenation modes in different environments using the same hyphenation > language. Yes, and my proposal doesn't impede those applications at all. Maybe I have some sort of deafness, but I keep not hearing objections that are squarely on point. I guess I need to re-apply the change in my working copy, update all the full-service macro packages except mom(7), and maybe present an example document. I have ideas on that front. > Like Peter, while I don't strongly oppose scoping the hyphenation > language to the environment, I don't see it as an improvement, and > certainly not as a bug fix as implied in > http://savannah.gnu.org/bugs/?66387#comment4 . Here's the meat of that comment for the benefit of observers. > $ cat EXPERIMENTS/buggy-hla.groff > .tm \n[.hla] > .ev spanish > .mso es.tmac > .tm .hla=\n[.hla], .hy=\n[.hy] > .ev > .tm .hla=\n[.hla], .hy=\n[.hy] > $ groff EXPERIMENTS/buggy-hla.groff > en > .hla=es, .hy=1 > .hla=es, .hy=4 > > Pretty weird to pop the environment stack and have the hyphenation > mode, but not the hyphenation language, change. > The change doesn't give users any new functionality; they can always > set the hyphenation language at any point. Again, this doesn't seem like a responsive objection. Let's survey most (or most) the stuff that's in the environment. Current Environment: previous type size: 10p (10000s) type size: 10p (10000s) previous requested type size: 10000s requested type size: 10000s valid type size list for selected font: 1000s-10000000s previous default family: 'T' default family: 'T' previous resolved font selection: 1 ('TR') resolved font selection: 1 ('TR') space size: 12/12 of font space width sentence space size: 12/12 of font space width previous line length: 468000u line length: 468000u previous title line length: 468000u title line length: 468000u previous line interrupted/continued: no filling: on alignment/adjustment: both previous vertical spacing: 12000u vertical spacing: 12000u previous post-vertical spacing: 0u post-vertical spacing: 0u previous line spacing: 1 line spacing: 1 previous indentation: 0u indentation: 0u temporary indentation: 0u temporary indentation pending: no total indentation: 0u previous text length: 0u target text length: 0u input line start: 0u computing tab stops from: input line start forcing adjustment: no hyphenation mode: 4 (on, not allowed within last two characters) hyphenation mode default: 4 count of consecutive hyphenated lines: 0 consecutive hyphenated line count limit: -1 (unlimited) hyphenation space: 0u hyphenation margin: 0u previous stroke color: default stroke color: default previous fill color: default fill color: default Environment 0: current Except for the "previous" stuff, _any_ of these could be yanked out of the environment and made global. And if anyone objected, I could say precisely this: "[you] can always set the [now-global parameter] at any point." Recall why (as best I can surmise) we have environments in the first place. Here's our Texinfo manual: ---snip--- Environments of themselves are not a source of non-linearity in document formatting: environment switches have immediate effect. One could always write a macro to change as many formatting parameters as desired with a single convenient call. But because diversions can be nested and macros called by traps that are sprung by other trap-called macros, they may be interpolated in varying contexts. For example, consider a page header that is always to be set in Helvetica. A document that uses Times for most of its body text, but Courier for displayed code examples, poses a challenge if a page break occurs in the middle of a code display; if the header trap assumes that the "previous font" is always Times, the rest of the example will be formatted in the wrong typeface. One could carefully save all formatting parameters upon entering the trap and restore them upon leaving it, but this is verbose, error-prone, and not future-proof as the 'groff' language develops. Environments save us considerable effort. ---end snip--- I think a formatter parameter should carry a greater burden to justify its status as global than as environmental. This is analogous to why local variables are better than global variables in imperative programming languages. > The scope of the hyphenation language ought to reflect the commonest > use cases. Even more importantly, the hyphenation language should be scoped so as to give the hyphenation mode a predictable meaning. See [1] again. > Scoping it to the environment does make it easier to support > multilingual documents that use environments to manage switching > languages. But is that a common enough use case to justify making it > the default behavior? I don't care--if it's more correct from a design and consistency perspective. While the odds might be slim and the audience small, if groff can do multilingual document preparation better than its competitors, then why not seize the opportunity? The cost seems pretty cheap--I already implemented the formatter side of it 2 years ago, after going down a blind alley with me(7) trying to accomplish the same end _without_ changing the formatter. > More common than, say, a monolingual document that has some text in > sidebars that demand looser hyphenation rules, and using environments > to switch between the main text and the sidebar text? My proposed change doesn't take that away. The best approach, I think, would be for packages to take care to copy from environment `0` when creating new environments (whether with my proposed "(1)" syntax below or the long-standing `evc 0`). If they forget, they can still do what you reassure us is easy--just invoke `hla $language_code` for every new environment they create, overriding the default of "en" (English). My proposal would still be better because you wouldn't have to invoke `hla $language_code` every time you _switched_ environments as well. > > Here is my proposal: > > > > (1) Extend the syntax of the `ev` request. Here is the pitch from > > comment #23 of Savannah #66392. > > Making environment management more flexible seems worthwhile > regardless of the consensus about hyphenation-language scope. Yes, if people can't stand the thought of adding `.evc 0` to their full-service macro packages (or documents, if they're expert-level users). > > (2) Adapt existing packages to the foregoing change. Frequently > > this will mean changing request sequences like this (from our > > "s.tmac"): > > > > .ev k > > .evc 0 > > .ev > > > > ...to this. > > > > .ev k 0 > > .ev > > What's the functional difference between these two? Nothing. Step 1 is not essential, but the previous spate of objections suggested to me that it would help the medicine of my proposal go down easier. If people no longer feel that way, it can be dealt with separately. 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". So, please, speak something obviously distinguishable from that into my ear trumpet. Regards, Branden [1] Here's the relevant part of groff's Texinfo manual. ---snip--- The automatic placement of hyphens in words is determined by "pattern files", which are derived from TeX and available for several languages. These files are named 'hyphen.XX' (for the patterns) and 'hyphenex.XX' (for a list of exceptions in languages that require them) where XX is an ISO 639 language code; see the table below. The number of characters at the beginning of a word after which the first hyphenation point should be inserted is determined by the patterns themselves; it can't be reduced further without introducing additional, invalid hyphenation points (unfortunately, this information is not part of a pattern file--you have to know it in advance). The same is true for the number of characters at the end of a word before the last hyphenation point should be inserted. For example, you can supply the following input to 'echo $(nroff)'. .ll 1 .hy 48 splitting You will get s- plit- t- in- g instead of the correct 'split- ting'. English patterns as distributed with GNU 'troff' need two characters at the beginning and three characters at the end; this means that value 4 of 'hy' is mandatory. Value 8 is possible as an additional restriction, but values 16 and 32 should be avoided, as should mode 1. Modes 4 and 6 are typical. ---end snip--- (Most of the foregoing is Werner's work, not mine.) [2] The sense I'm familiar with is via Watt, Wichmann, and Findlay. ---snip--- ... Observing that the quality of a design is related to the ease with which the program can be implemented, tested and modified, Yourdon and Constantine suggest that the program should be composed of modules that are small, implementable individually, testable individually, modifiable individually, and that bear a simple relationship to some aspect the application. Now these criteria are somewhat subjective and difficult to define, so Yourdon and Constantine propose two technical criteria that can be defined more precisely. These criteria are _coupling_ and _cohesion_. _Coupling_ is concerned with interconnections between modules. ... A module *A* is said to be _tightly coupled_ to another module *B* if it has many dependencies on *B*, or if any of these dependencies are complex. *A* is _loosely coupled_ to *B* if it has few, simple dependencies on *B*. In general, all else being equal, a loosely coupled design is preferable to a tightly coupled design. Of course coupling cannot be avoided altogether: the modules of a program must cooperate in some way! The more tightly modules are coupled, however, the more difficult they will be to implement, test, and modify individually. ... Unlike coupling, _cohesion_ is a property of an individual module. A module is said to be _strongly cohesive_ if it is responsible for a single function. A module that is responsible for two or more distinct functions is said to be _weakly cohesive_. A weakly cohesive module could probably be split into two or more modules, each of which would be smaller, simpler, and therefore easier to implement, test, and modify. ... ---end snip--- (italics/emphasis in original) _Ada Language and Methodology_, Prentice Hall, 1987, pp. 215-216. Applying the foregoing perspective, I think GNU troff's environments would be more _cohesive_ if they managed the hyphenation language together with the hyphenation mode. Doing so weakens the _coupling_ between the global list of settings and the environment. As noted above, the very validity of the hyphenation mode is dependent on the selection of hyphenation language.
signature.asc
Description: PGP signature
