Follow-up Comment #18, bug #66054 (group groff): [comment #14 comment #14:] > [comment #12 comment #12:] > > Oh, I see. I thought the 3rd résumé wouldn't hyphenate, but it did. > > I'm not sure whether anything here needs to be fixed, because > I don't know if this is expected behavior.
Branden's comment #12 showed this was not behavior _he_ expected.
To recap, the "3rd résumé" comes from this input:
.ll 1n
r\['e]sum\['e]
.hcode é e \" sets up a mapping
r\['e]sum\['e]
.hcode é é \" undoes that mapping, maybe?
r\['e]sum\['e] \" ... what happens now?
What made the behavior unexpected to _me_ is that you can get this break point
by trimming this example down:
.ll 1n
r\['e]sum\['e]
.hcode é é \" sets an hcode but maps it to no existing ones
r\['e]sum\['e] \" ... what happens now?
which has long (going back to at least groff 1.19.2) produced:
résumé
ré-
sumé
The reason this surprised me is that the English patterns and exceptions list
contain only ASCII characters. So a nonzero hcode for é, not mapped to
anything in ASCII, shouldn't be able to change any break points.
The light bulb finally clicked on when I (re)read Werner's explanation in the
info manual (also dating back to at least groff 1.19.2, and substantially
unchanged today; quoted in full in comment #10) about how hyphenation for the
word "Kindergärten" worked without and without the additional .hcodes in that
example.
I think that resolves the last remaining mystery in my head about this bug.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66054>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
