Fixes #5275. Clear stale TextView OSC 8 hyperlinks

[harder]

Summary

Fixes the stale OSC 8 hyperlink state in TextView when links come from plain-text URL auto-detection rather than explicit Link views.

• Fixes TextView plain-text OSC 8 hyperlinks are not fully cleared after scroll or delete-all #5275

Changes

• Split output-buffer URL tracking so explicit links and auto-detected plain-text URLs are synchronized independently.
• Reused Osc8UrlLinker URL-range detection to map auto-detected URLs into per-cell output state before rendering.
• Updated row rendering to emit OSC 8 close sequences when a row previously had hyperlinks but no longer does after redraw, scroll, or delete-all.
• Added regression coverage for overwriting auto-detected URLs with plain text and spaces.
• Preserved the explicit-link path fixed by Fixes #4892. OSC 8 hyperlink rendering does not clean up #5254; this addresses a separate pre-existing bug in the plain-text auto-linking path.

Testing

• dotnet build --no-restore
• dotnet test --project Tests/UnitTestsParallelizable --no-build

To pull down this PR locally:

git remote add copilot https://github.com/harder/Terminal.Gui.git
git fetch copilot harder/issue-5275-textview-osc8
git checkout copilot/harder/issue-5275-textview-osc8

[harder]

Code review

Found 3 issues:

1. Auto-URL detection treats raw char offsets as column indices, which breaks for any multi-codepoint grapheme cluster (.claude/rules/unicode-graphemes.md says "Think in graphemes, not runes" and warns against treating char counts as terminal cells).

SyncAutoUrlsForRowCore builds rowText by appending each cell's Grapheme — that string can be 1 char ("a"), 2 chars ("é" = 'e' + U+0301), or 8+ chars (ZWJ emoji like 👨‍👩‍👦). It then passes the concatenation to FindUrls and uses range.Start directly as a column index. For a row like 🚀 https://example.com, the URL's char offset in rowText diverges from its column position, so _autoUrlMap tags the wrong cells and the link visibly drifts off the URL. Test coverage uses ASCII so this is invisible to the new tests.

Terminal.Gui/Terminal.Gui/Drivers/Output/OutputBufferImpl.cs

Lines 478 to 496 in ad1127d

	StringBuilder rowText = new (Cols);
	for (int col = 0; col < Cols; col++)
	{
	string grapheme = Contents [row, col].Grapheme;
	rowText.Append (string.IsNullOrEmpty (grapheme) ? " " : grapheme);
	}
	foreach (Osc8UrlLinker.UrlRange range in Osc8UrlLinker.FindUrls (rowText.ToString ()))
	{
	int end = Math.Min (range.Start + range.Length, Cols);
	for (int col = range.Start; col < end; col++)
	{
	_autoUrlMap ??= [];
	_autoUrlMap [new Point (col, row)] = range.Url;
	}
	}
	}

2. _rowsWithUrls (on OutputBase) is never cleared when the buffer is reset, so stale row indices survive across ClearContents/SetSize.

OutputBufferImpl.ClearContentsCore clears both URL maps, but OutputBase._rowsWithUrls lives in a different class and is not notified. After a resize or clear, the next render sees rowHadUrlsPreviously = true for stale rows; if the new content has no URLs there, a spurious OSC_EndHyperlink() is prepended at the start of those rows. Mostly cosmetic, but a real correctness drift between the two structures — consider exposing a ClearUrlState() on OutputBase that callers invoke from ClearContents/SetSize, or computing rowHadUrlsPreviously from the buffer's maps directly.

Terminal.Gui/Terminal.Gui/Drivers/Output/OutputBufferImpl.cs

Lines 310 to 315 in ad1127d

	DirtyLines = new bool [Rows];
	_explicitUrlMap?.Clear ();
	_autoUrlMap?.Clear ();
	for (var row = 0; row < Rows; row++)

3. The GetCellUrl fast-path is defeated for the lifetime of the buffer once any URL is ever set (a Copilot reviewer flagged the same anti-pattern in Fixes #5193. Emit OSC 8 hyperlink sequences in Driver.ToAnsi() #5195).

ClearContentsCore calls .Clear() on both maps but does not null them, so after the first URL is ever assigned both _explicitUrlMap and _autoUrlMap stay non-null forever. The null fast-path in GetCellUrl then always misses, and the newly added RowContainsUrls adds another full-row scan per dirty row — roughly an extra 1920 lock acquisitions per frame on a 24×80 buffer with no URLs. Setting the maps to null in ClearContentsCore (and after SyncAutoUrlsForRowCore finds zero matches, where applicable) restores the optimization.

Terminal.Gui/Terminal.Gui/Drivers/Output/OutputBufferImpl.cs

Lines 64 to 82 in ad1127d

	public string? GetCellUrl (int col, int row)
	{
	if (_explicitUrlMap is null && _autoUrlMap is null)
	{
	return null;
	}
	lock (_contentsLock)
	{
	Point point = new (col, row);
	if (_explicitUrlMap?.TryGetValue (point, out string? explicitUrl) == true)
	{
	return explicitUrl;
	}
	return _autoUrlMap?.TryGetValue (point, out string? autoUrl) == true ? autoUrl : null;
	}
	}

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[harder]

I've extensively tested with multiple agents and models trying various angles to fix the two root issues observed in #5275:

1. After hovering a link and scrolling with the mouse wheel, the underline can appear on the wrong text and move with the mouse cursor instead of staying on the actual link.
2. After selecting all text and deleting it, the deleted links can still appear hoverable at their former screen locations.

They did find and fix several small bugs related to OSC 8 handling that should make Terminal.Gui as compliant as possible. But were not able to fix the root issue, and after testing with various terminals and AI agent analysis of the Windows.Terminal codebase, I believe the root cause is a Windows Terminal bug.

Observations:

1. In Windows Terminal in Windows 11 on my Surface ARM-based laptop, I still see both issues above (1 and 2).
2. In Warp terminal on MacOS, I see issue 1 above (have never seen issue 2). Claude found a known issue in Warp that explains issue 1, and Warp does it's own custom link regex parsing that prevents it from being affected by issue 2.
3. In iTerm2 terminal on MacOS, I cannot reproduce either issue. iTerm2 is known for its reference-quality OSC8 support.

If anyone has other terminals they can test with, I'd appreciate it.

I am going to file a bug report in the Microsoft Terminal project with repro details. The other OSC8 related bug fixes in this PR can be reviewed and merged.