[insjang]

Two places where the emulator departed from what programs written for xterm expect.

Back color erase. Erasing wrote cells with no style, so they took the terminal's own background. Every colour terminal (xterm's "bce") erases in the background currently set, and programs rely on it: a run of a line is coloured by setting a background and erasing to the end of it, which is how a status line, a selection highlight or a table cell gets painted wider than its text. Without it such a run kept the terminal colour from its last character on. EL, ED and ECH now erase in the current background, and so do the cells that ICH opens and DCH uncovers, as in xterm; only the background carries over, not bold or underline.

Pending wrap. With deferred wrapping (DECAWM as xterm does it) a character written to the last column leaves the cursor there with a wrap pending. DEC STD 070 lists what clears that state: CR, LF, IND, RI, NEL, the cursor movement sequences, and the erase, insert and delete sequences. The emulator cleared it only on a column move, so a line feed or a cursor-down after a full row still wrapped the next character a row further down and marked an unrelated row as wrapped - which showed up as unrelated rows joined when copying from a full screen program.

Tests cover the backgrounds of each erase and of ICH/DCH, and the reset of the pending wrap by LF, cursor line moves and ECH.

[github-actions]

Test Results

    54 files  ± 0      54 suites  ±0   36m 20s ⏱️ - 1m 4s
 4 978 tests + 5   4 956 ✅ + 5   22 💤 ±0  0 ❌ ±0 
12 825 runs  +15  12 671 ✅ +15  154 💤 ±0  0 ❌ ±0 

Results for commit 81c9981. ± Comparison against base commit c49150d.

♻️ This comment has been updated with latest results.

[insjang]

Rebased on master (with #2894 in), one commit, f9c9d44; all terminal tests pass.

Merging with #2894 turned up one more case, fixed here: erasing half of a wide character left the other half blank in the terminal's own colour. Both cells of a wide character are now erased in the current background, as the rest of the range, so the expectations of three wide character tests in VT100EmulatorBackendTest change from a space to an empty cell, and testEraseHalfOfWideKeepsBackground covers it.

How to test, in a runtime Eclipse with this org.eclipse.terminal.control, Terminal view, local shell:

1. Back color erase: printf '\e[42mstatus\e[K\e[0m\n'
   Expected: the green runs to the right edge of the view. Before this change only "status" was green.
2. The same with ED and ECH: printf '\e[44m\e[2J\e[H\e[0m'; sleep 1; clear paints the whole screen blue for a second; printf 'abcdef\r\e[41m\e[3X\e[0m\n' shows three red cells over "abc".
3. Only the background carries over: printf '\e[1;4;42m\e[K\e[0m\n' gives a green line with no underline.
4. Half of a wide character: printf '한글한글\r\e[C\e[42m\e[K\e[0m\n'
   Expected: the whole line is green from the first cell on, with no dark half cell where 한 was.
5. Pending wrap: in a view 20 columns wide, printf '%020d\n' 0; echo next
   Expected: "next" is on the line right below the zeros, not one further down, and copying the two lines gives two lines, not one joined line.
6. Full screen programs that paint their status line with a background, such as htop, mc or vim with a coloured status line, show the colour across the whole width.

Unit tests: VT100EmulatorBackendTest (testEraseKeepsBackground, testEraseHalfOfWideKeepsBackground, testPendingWrapForgottenByCursorMove).

[Copilot]

🟡 Changes recommended

The change introduces quadratic erasure work with per-cell snapshot notifications and causes full reset to retain a non-default background instead of restoring the default.

2 open issues

• Reset style before clearing the display on full reset · New
• Batch whole-line erasure to avoid quadratic array growth · New

What changed in this PR

This PR brings the terminal emulator closer to xterm behavior by preserving the current background during erasure and clearing pending wraps when the cursor moves.

Changes:

• Applies background-aware erasure to erase operations and cells exposed by character insertion or deletion.
• Clears pending-wrap state on vertical cursor movement, line feeds, and erasure.
• Adds regression tests for background preservation, wide-character erasure, and pending-wrap handling.

File	Description
terminal/​tests/​org.eclipse.terminal.test/​src/​org/​eclipse/​terminal/​internal/​emulator/​VT100EmulatorBackendTest.java	Adds background and wrap tests; updates wide-character erase expectations.
terminal/​bundles/​org.eclipse.terminal.control/​src/​org/​eclipse/​terminal/​internal/​emulator/​VT100EmulatorBackend.java	Centralizes background-aware erasure and resets pending wraps on movement.

_{Review effort: Balanced}

[akurtakov]

Thanks, back color erase is a real gap and the pending wrap reset on line moves matches DEC STD 070. Two things need fixing before this can go in; both are in Copilot's threads, with details below. After that there's a question about scrolling and a small nit, neither blocking.

[Copilot]

🟡 Changes recommended

Whole-line erasure with the default background leaves deferred wrapping pending, causing subsequent text to move to the next row and incorrectly marking the erased row as wrapped.

2 open issues

• Whole-line erasure leaves deferred wrapping pending · New
• Reset style before clearing the display on full reset

1 resolved since last review

• Batch whole-line erasure to avoid quadratic array growth

_{Review effort: Balanced}

[insjang]

@akurtakov all review points are addressed in 81c9981, including Copilot's follow-up (erasing a whole line in default colours also forgets a pending wrap). Filling the lines that scrolling brings in is left for a follow-up, as the commit message says. Could you take another look?

[Copilot]

🟢 Approval recommended

No active review issues were identified for the terminal erasure and wrap-cancellation changes.

No open issues 🎉

2 resolved since last review

• Whole-line erasure leaves deferred wrapping pending
• Reset style before clearing the display on full reset

_{Review effort: Balanced}

[akurtakov]

Thanks. It's nice to not see visual glitches in midnight commander.