Fixed word wrapping emitting a blank row for trailing whitespace

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.

[fdesbiens]

What this fixes

b8bb23b8 (#159) fixed issue #130 by letting the overflow branch of _gx_multi_line_text_view_display_info_get() run when an ASCII space is the character that overflows the available width. That branch consumes the space and any consecutive spaces without adding them to the row width — correct — and then breaks.

When the whitespace ran to the end of the source line, the line terminator was left behind. The next call started on it, hit the GX_KEY_LINE_FEED case immediately, and returned a row of one byte and zero width: a blank line that is not in the text.

The overflow branch now takes the line terminator with the whitespace when nothing else separates them, handling both a bare line feed and a \r\n pair, with the second byte guarded on the remaining length. gx_text_display_width is untouched, so the #130 fix stands.

Why two golden tests have been red since June

guix_ml_text_view_32bpp (268 of 300 frames) and guix_bidi_text_draw_32bpp (144 of 429) have failed in every CI run since #159 landed.

Two phantom rows appear in the guix_ml_text_view_32bpp fixture, at string offsets 2992 and 23988 of readme_guix_generic.txt: ...Improved internal logic. with twelve trailing spaces, and ...cursor_pos_calculate.c with one. Both were confirmed with a conditional breakpoint on display_number == 1 && display_width == 0 preceded by a space — it fires exactly twice on the pre-fix code and never after.

Nothing inside GUIX reads gx_text_display_width; every caller uses only gx_text_display_number, to advance its index. So the row count alone governs where every row starts, and two extra rows change the scrollbar's value-to-pixel mapping. Every scroll step then lands at a slightly different pixel offset and the whole text block is drawn a few pixels up or down. Of the 300 frames, 297 were a pure vertical shift of otherwise identical text; only 3 were laid out differently, and those 3 are the two places above.

No golden data is regenerated.gx_multi_line_text_view_text_total_rows for the long text view goes back from 2226 to 2224, and both tests pass against their existing golden files.

Test work

guix_ml_text_view_word_wrap_no_output did not protect #159's fix — it passed on the pre-#159 code too. Its available_width was one pixel too generous (a_width + space_width), so the over-wide row the old code produced measured exactly available_width and still satisfied width <= available_width.

It is now a_width + space_width - 1, and three cases are added:

1. a line feed terminator,
2. a \r\n terminator,
3. the total row count _gx_multi_line_text_view_string_total_rows_compute() derives from them — the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data.

Verified to discriminate in both directions by rebuilding against each source state:

Source state	Test outcome
pre-b8bb23b8	Fails 4 width <= available_width assertions (issue #130)
b8bb23b8 as shipped	Fails LF row (2 bytes, not 3), \r\n row (2, not 4), row count (3, not 2)
this PR	Passes

Verification

Linux, all eighteen build configurations, 1847 tests, no failures.

Configuration	Result
default_build_coverage	733/733 — guix_ml_text_view_32bpp green against unmodified golden
dynamic_bidi_text_build	3/3 — guix_bidi_text_draw_32bpp green against unmodified golden
no_utf8_build_coverage	135/135
the other 15	all pass

One coverage boundary worth naming: the unit test builds against the all_widgets demo, which is not in NO_UTF8_DEMOS, so it runs in default_build_coverage and disable_error_check_build but not in the GX_UTF8_SUPPORT-off configurations. The changed code is common to both paths — only the surrounding character advance differs — and no_utf8_build_coverage covers it through its 135 golden tests.

No documentation change is required: _gx_multi_line_text_view_display_info_get is internal, and the GUIX documentation does not describe multi-line text view wrapping behaviour for trailing whitespace.