Follow-up Comment #20, bug #66919 (group groff): [comment #19 comment #19:] > At 2025-03-22T14:01:14-0400, Dave wrote: >> It can either do what it has always done, which is to generate a new, >> unique hyphenation code; > > I quibble with the word "generate" here.
I was speaking in the abstract--or, perhaps more pertinently, within what is
documented, which, as you note, omits (with good reason) implementation
details. But I appreciate the mathematical detail in which you quibbled. ;-)
> Here's where I disagree with your model. I'd have to dig deeper into
> the startup code to be sure, but _conceptually_, when GNU troff
> initializes hyphenation codes, they're a perfect image of the character
> code values. It then goes through each of them and "fixes them up".
I disagree with your adverb. _Conceptually_, the user is presented with a
startup state where certain characters have certain hyphenation codes. What
those codes are, and how they got initialized, are irrelevant to the user's
conceptual framework. Without delving into the code, the user knows what's
presented in the documentation, which is that A-Z have hyphenation codes that
map to a-z--but, intentionally, not what those codes _are_. That's beyond the
conceptual model; that's an implementation detail, one that's undocumented and
therefore not guaranteed to remain the same across releases. (Or even, as far
as the user knows, across multiple runs of the same groff executable.)
Most users then have additional hyphenation codes added by groff startup
files. How those get added is more discoverable to the casual user, because
they're in startup files to which the user has direct access, and that are
written in roff syntax. The manual documents the fact that startup files will
likely set some additional hyphenation codes, though for obvious reasons gives
no further detail.
I submit that the foregoing is the extent of the user's _conceptual_
framework.
This may sound like some hair-splitting semantics, but it's laying groundwork
for some practical points I'll get to later.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66919>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
