Fixed word-wrapping: space at overflow no longer exceeds available_width by fdesbiens · Pull Request #159 · eclipse-threadx/guix

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-02T14:51:55Z

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue #130.

Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path).

UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80.

Files changed:

gx_multi_line_text_view_display_info_get.c

Regression test added:

Space at overflow: gx_text_display_width <= available_width.
Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space).
Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number.
Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression).

Closes#130

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

In _gx_multi_line_text_view_display_info_get() the overflow condition had a guard (ch.gx_string_ptr[0] != ' ') that prevented the overflow branch from executing when an ASCII space caused overflow. The space was instead added to gx_text_display_width, making it exceed available_width — the bug reported in issue eclipse-threadx#130. Remove the guard and handle the space case explicitly: consume the overflowing space plus any immediately-following consecutive spaces in gx_text_display_number without adding to gx_text_display_width, then break. The trailing-spaces loop ensures that multiple spaces at the overflow boundary are all consumed so the next line starts at the next word (matching the behaviour of the old checkpoint-save path). UTF-8 safety: ASCII 0x20 comparisons in the while loop are byte-safe because UTF-8 continuation bytes are always >= 0x80. Files changed: - gx_multi_line_text_view_display_info_get.c Regression test added: 1. Space at overflow: gx_text_display_width <= available_width. 2. Space at overflow: gx_text_display_number includes the trailing space (next line does not start with a space). 3. Multiple consecutive spaces at overflow: all trailing spaces are consumed in gx_text_display_number. 4. Normal word overflow (non-space char): backtrack to last word boundary still works correctly (no regression). Closeseclipse-threadx#130 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

b8bb23b (#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, which is 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, which draws as 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 a bare line feed and a carriage return / line feed pair, and guarding the second byte on the remaining length -- unlike the pre-existing GX_KEY_CARRIAGE_RETURN case earlier in the same loop, which reads ch.gx_string_ptr[1] unchecked. gx_text_display_width is untouched, so the issue #130 fix stands. Two such 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 and display_width == 0 preceded by a space, which fires exactly twice on the pre-fix code and never after. The two extra rows are why 268 of that test's 300 frames and 144 of guix_bidi_text_draw_32bpp's 429 frames have differed from their golden data since June. 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. guix_ml_text_view_word_wrap_no_output did not protect #159's fix: it passed on the pre-#159 code as well. 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, which makes appending the space genuinely overflow, and three cases are added: a line feed terminator, a carriage return / line feed terminator, and the total row count that _gx_multi_line_text_view_string_total_rows_compute() derives from them. That last one is the quantity the golden frames actually depend on, and the only one of the three a unit test can pin without golden data. The test was verified to discriminate in both directions by rebuilding against each. Against the pre-#159 source it fails four width assertions, which is issue #130. Against #159 as shipped it fails the line feed row (2 bytes, not 3), the carriage return / line feed row (2, not 4) and the row count (3, not 2). It passes only with both fixes in place. Verified on Linux across all eighteen build configurations, 1847 tests, no failures. default_build_coverage 733/733, dynamic_bidi_text_build 3/3 including guix_bidi_text_draw_32bpp, no_utf8_build_coverage 135/135. 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. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens merged commit b8bb23b into eclipse-threadx:devJun 2, 2026
1 check passed