[self-follow-up] I feel I was inadequately clear in making one of my points; this message likely would have benefitted from a probationary period in my draft folder and a revision pass.
At 2026-03-17T22:10:59-0500, G. Branden Robinson wrote:
> At 2026-03-17T21:07:13-0500, Dave Kemper wrote:
> > 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.
This statement is, superficially, hard to square with my quote of Watt,
Wichmann, and Findlay regarding "coupling" and "cohesion". They apply
these concepts to software modules; here, what's under discussion in
this thread are two GNU troff configuration parameters that are housed
and managed _within_ software modules, as it were.
It might have been more illuminating on my part to stick with WW&F's
domain of application for these terms and use a different mode of
analysis for specific configuration parameters: namely data dependency,
as one grapples with when designing the tables of a relational database.
To wit...
> 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.
I assert that there exists a data dependency of the hyphenation mode
upon the hyphenation language. If we imagine a third datum, a list
labelled "hyphenation eligibility points" that indexed hyphenation break
points within a word, maybe this becomes more clear. There is in fact a
comment in GNU troff's source code illustrating something similar.
// The position of a hyphenation point gets marked with an odd
// number. Example:
//
// hbuf: . h e l p f u l .
// num: 0 0 0 2 4 3 0 0 0 0
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?h=1.24.1#n4565
...except in this case I'm imagining something more abstract. Consider
a word of arbitrary length.
f o o b a r . . . b a z q u x
1 2 3 4 5 6 -6 -5 -4 -3 -2 -1
The hyphenation mode configures which of the first and last three
positions are available for hyphenation breaking, _if_ the
language-specific pattern files are written to permit breaking at those
positions. The data have to be aligned with each other.
As quoted in my previous message, Werner wrote:
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.
That statement is less true than it used to be; TeX's hyphenation
patterns now frequently _do_ contain these data in the form of a
comment.
$ git grep 'left.*hyph.*min' tmac
tmac/LOCALIZATION: \lefthyphenmin=2, \righthyphenmin=2 => 1
tmac/LOCALIZATION: \lefthyphenmin=2, \righthyphenmin=3 => 4
tmac/LOCALIZATION: \lefthyphenmin=1, \righthyphenmin=2 => 32
tmac/cs.tmac:.\" Czech hyphenation (\lefthyphenmin=2, \righthyphenmin=2)
tmac/de.tmac:.\" German hyphenation (\lefthyphenmin=2, \righthyphenmin=2)
tmac/en.tmac:.\" English hyphenation (\lefthyphenmin=2, \righthyphenmin=3)
tmac/es.tmac:.\" Spanish hyphenation (\lefthyphenmin=2, \righthyphenmin=2)
tmac/fr.tmac:.\" French hyphenation (\lefthyphenmin=2, \righthyphenmin=3)
tmac/hyphen.sv:% correctly if \lefthyphenmin>=1 and \righthyphenmin>=2.
tmac/it.tmac:.\" Italian hyphenation (\lefthyphenmin=2, \righthyphenmin=2)
tmac/pl.tmac:.\" Polish hyphenation (\lefthyphenmin=2, \righthyphenmin=2)
tmac/ru.tmac:.\" Russian hyphenation (\lefthyphenmin=2, \righthyphenmin=2)
tmac/sv.tmac:.\" Swedish hyphenation (\lefthyphenmin=1, \righthyphenmin=2)
> You might not be using "coupling" in a sense with which I'm
> familiar.[2]
Coupling and data dependency are different modes of analysis, even if
determinations in one imply consequences in the other, and I'm afraid I
may have only contributed to confusion by adopting the terminology you
offered and running with it without first (re-)defining terms or
challenging you to apply different ones.
I'll quote the "bottom line" of my previous message for emphasis.
> ... 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.
Regards,
Branden
signature.asc
Description: PGP signature
