Visual corruption / Text bleeding from statusline when wrapping long Unicode lines without spaces (wordwrap + softwrap)

[ovmonk]

When both softwrap and wordwrap are enabled, opening a file with a very long line consisting entirely of Unicode characters (like box-drawing characters ──────) with no spaces causes severe visual rendering corruption.

The wrapping logic seems to miscalculate the column width/offset. When it fails to find a word boundary to wrap, the screen buffer overflows or fails to refresh correctly, causing characters from the statusline/infobar (such as the current file path) to "bleed" and get interspersed into the wrapped code line.

Environment:

• Micro Version: 2.0.15 (Commit hash: 6a62575, Compiled on February 18, 2026)
• OS: fedora Linux 44 (i3wm)
• Terminal: Alacritty (with truecolor enabled)

Minimal settings.json to Reproduce:

{
    "softwrap": true,
    "wordwrap": true,
    "truecolor": "on"
}

Steps to Reproduce:

1. Enable softwrap and wordwrap in settings.json.
2. Open a file with a long path (e.g., ~/.config/i3/scripts/screenshot.sh).
3. Create a very long line of continuous Unicode box-drawing characters that exceeds the terminal window width (with absolutely no spaces), for example:

└──────────────────────────────────────────────────────────────────────────┘

4. Observe the rendering of the wrapped portion at the end of the line.

Expected Behavior:

The line should fallback to character-based wrapping cleanly when no spaces are found, without corrupting the grid matrix or bleeding text from the statusline.

Actual Behavior:

The text from the statusline (the file path) gets fragmented and injected into the wrapped Unicode line.

For example, instead of a clean wrapped line, the last line renders like this:

└─-/-c-n-i-/-3-s-r-p-s-s-r-e-s-o-.-h-

(Where -c-n-i-/-3-s-r-p-s-s-r-e-s-o-.-h- is the scattered remnants of ~/.config/i3/scripts/screenshot.sh leaking into the viewport matrix).

Running cat on the file confirms the actual file content is perfectly intact; this is strictly a display/tcell rendering artifact. Disabling wordwrap ("wordwrap": false) instantly fixes the artifact.

Additional Context:

It seems the wordwrap algorithm doesn't gracefully handle the edge case where a line is too long but contains zero whitespace, especially when combined with multibyte Unicode characters. The rendering pointer seems to drift into the statusline's memory buffer during the screen refresh cycle.

Environment

• Version: 2.0.15 (Commit hash: 6a62575, Compiled on February 18, 2026)
• OS:fedora Linux 44 (i3wm)
• Terminal:Alacritty (with truecolor enabled)

[JoeKar]

Currently I can't reproduce this with ptyxis.
Can you try this with a different terminal on your system?

It seems the wordwrap algorithm doesn't gracefully handle the edge case where a line is too long [...]

But it actually does by checking against the bufWidth of the buffer window. 🤔