Follow-up Comment #5, bug #68515 (group groff): At 2026-07-14T10:03:48-0400, Dave wrote: > Follow-up Comment #4, bug #68515 (group groff): > > [comment #2 comment #2:] >> But it does not match the "expected output" in the comments of the >> script. > > This "expected output" comes from examples in bug #66054. But in > comment 19 there, Branden explains why the formerly expected output is > no longer expected: > > "In _groff_ 1.23.0, é had a hyphenation code of 0. In _groff_ 1.24.0, > it has a hyphenation code of 233 (because these are set up in > 'latin1.tmac' now)." > > So as of 1.24.0, the latin1.tmac setup file is invalidating the test > that hcode-request-copies-spec-char-code.sh tries to run. > > While this doesn't entirely explain the July-10-build behavior, we do > now know the script isn't testing .hcode per se.
Ahh.
> But it _is_ still testing actual hyphenation behavior, which is the
> aspect of hyphenation codes that users care about, and something
> hcode-request-works.sh does not do. But there might be other tests
> that already cover that (I haven't looked).
I don't think we have a lot of coverage of "high-level" hyphenation
behavior; we better cover fiddly little atomic aspects of behavior.
Which is important, but it's not everything.
src/roff/groff/tests/hcode-request-works.sh
src/roff/groff/tests/hla-request-works.sh
src/roff/groff/tests/hw-request-skips-only-invalid-arguments.sh
src/roff/groff/tests/hys-request-works.sh
(By the way, I've got unit tests for the `hpf` and `hpfa` requests on
the cooker.)
If this test, hcode-request-copies-spec-char-code.sh, works as-is as a
sort of integration test for hyphenation, then we can rename and
annotate it accordingly.
Maybe "hyphenation-integration.sh"...?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68515>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
