guix_ml_text_view_word_wrap_no_output is the white-box unit test for _gx_multi_line_text_view_display_info_get(). #177 strengthened it so that it discriminates both issue #130 and the blank-row regression #159 introduced, and verified it fails against each of those source states.
It runs in only two of the eighteen build configurations: default_build_coverage and disable_error_check_build. Both have GX_UTF8_SUPPORT on.
Why
The test is listed in all_widgets_REG_TESTS in test/guix_test/cmake/regression/CMakeLists.txt, so it is built against the all_widgets demo. all_widgets is in OTHER_DEMOS, not in NO_UTF8_DEMOS, and the configuration selects one demo set or the other. A test cannot simply be added to a second list — it needs a variant written against a demo that the non-UTF8 configurations build.
What this leaves uncovered
The function has two character-advance paths:
#ifdef GX_UTF8_SUPPORT
_gx_utility_utf8_string_character_get(&string, GX_NULL, &glyph_len);
current_index += glyph_len;
#else
string.gx_string_ptr++;
string.gx_string_length--;
#endifEverything the unit test asserts — the overflow branch, trailing-whitespace consumption, line-terminator accounting, the resulting row count — sits below that #ifdef and is common to both paths. Only the advance differs, and with glyph_len fixed at 1 the two are equivalent for the ASCII fixtures the test uses. So the risk is low.
It is not zero, though. glyph_len is the quantity the overflow branch adds to gx_text_display_number, and it is only ever set by the UTF-8 path; on the non-UTF-8 path it keeps its initialiser of 1. A future change to how the row length is accumulated could diverge between the two without any unit test noticing.
no_utf8_build_coverage does exercise the non-UTF-8 path today, but only through its 135 golden-frame tests — which is exactly the kind of coverage that told us that something changed without telling us what, and that took a fair amount of gdb work to turn into a diagnosis in #177.
Suggested work
Add a variant of the test built against a demo in NO_UTF8_DEMOS, asserting the same properties. The test body is largely portable as written; the setup (widget creation, font lookup through root) is what needs adapting to the chosen demo.
Not urgent — filed so it is not lost.
guix_ml_text_view_word_wrap_no_outputis the white-box unit test for_gx_multi_line_text_view_display_info_get(). #177 strengthened it so that it discriminates both issue #130 and the blank-row regression #159 introduced, and verified it fails against each of those source states.It runs in only two of the eighteen build configurations:
default_build_coverageanddisable_error_check_build. Both haveGX_UTF8_SUPPORTon.Why
The test is listed in
all_widgets_REG_TESTSintest/guix_test/cmake/regression/CMakeLists.txt, so it is built against theall_widgetsdemo.all_widgetsis inOTHER_DEMOS, not inNO_UTF8_DEMOS, and the configuration selects one demo set or the other. A test cannot simply be added to a second list — it needs a variant written against a demo that the non-UTF8 configurations build.What this leaves uncovered
The function has two character-advance paths:
Everything the unit test asserts — the overflow branch, trailing-whitespace consumption, line-terminator accounting, the resulting row count — sits below that
#ifdefand is common to both paths. Only the advance differs, and withglyph_lenfixed at 1 the two are equivalent for the ASCII fixtures the test uses. So the risk is low.It is not zero, though.
glyph_lenis the quantity the overflow branch adds togx_text_display_number, and it is only ever set by the UTF-8 path; on the non-UTF-8 path it keeps its initialiser of 1. A future change to how the row length is accumulated could diverge between the two without any unit test noticing.no_utf8_build_coveragedoes exercise the non-UTF-8 path today, but only through its 135 golden-frame tests — which is exactly the kind of coverage that told us that something changed without telling us what, and that took a fair amount of gdb work to turn into a diagnosis in #177.Suggested work
Add a variant of the test built against a demo in
NO_UTF8_DEMOS, asserting the same properties. The test body is largely portable as written; the setup (widget creation, font lookup throughroot) is what needs adapting to the chosen demo.Not urgent — filed so it is not lost.