Add support for tabbing to embedded hyperlinks

[carlos-zamora]

Summary of the Pull Request

There's already logic to tab to a hyperlink when we're in mark mode. We do this by looking at the automatically detected hyperlinks and finding the next one of interest. This adds an extra step afterwards to find any embedded hyperlinks and tab to them too.

Since embedded hyperlinks are stored as text attributes, we need to iterate through the buffer to find the hyperlink and it's buffer boundaries. This PR tries to reduce the workload of that by first finding the automatically detected hyperlinks (since that's a fairly quick process), then using the reduced search area to find the embedded hyperlink (if one exists).

Validation Steps Performed

In PowerShell, add an embedded hyperlink as such:

${ESC}=[char]27
Write-Host "${ESC}]8;;https://github.com/microsoft/terminal${ESC}\This is a link!${ESC}]8;;${ESC}\"

Enter mark mode (ctrl+shift+m) then shift+tab to it.
✅ The "This is a link!" is selected
✅ Verified that this works when searching forwards and backwards

Closes #18310
Follow-up from #13405
OSC 8 support added in #7251

[DHowett]

qq: do we have a way to iterate by attribute instead of by cell?

[carlos-zamora]

Sorta, but it makes things more complicated and it's not really worth it imo.

We could use row.Attributes().runs() kinda like TextBuffer::ClearMarksInRange() here:

terminal/src/buffer/out/textBuffer.cpp

Lines 3462 to 3479 in 7423dd3

	void TextBuffer::ClearMarksInRange(
	const til::point start,
	const til::point end)
	{
	auto top = std::clamp(std::min(start.y, end.y), 0, _height - 1);
	auto bottom = std::clamp(std::max(start.y, end.y), 0, _estimateOffsetOfLastCommittedRow());
	for (auto y = top; y <= bottom; y++)
	{
	auto& row = GetMutableRowByOffset(y);
	auto& runs = row.Attributes().runs();
	row.SetScrollbarData(std::nullopt);
	for (auto& [attr, length] : runs)
	{
	attr.SetMarkAttributes(MarkKind::None);
	}
	}
	}

So we'd be able to get the length of each attribute run, but the combination of search direction (searching backwards with this system is hard) and support for wrapped hyperlinks makes this more complicated than it's worth, imo.

[DHowett]

(blocking so i see it later in my list of PRs)

[lhecker]

Just a minor nits about iterators, and a question about the loop boundaries!

[lhecker]

This is kind of obtuse IMO, but even after thinking about it for a while I can't think of a better way to write this. One option may to explicitly split it up into

if (dir == SearchDirection::Forward) {
} else {
}

[lhecker]

Always write --hyperlinkStartIter if you don't want the previous result.

[lhecker]

If the hyperlink starts at the origin of the search, couldn't this accidentally leave the boundaries of it?

[lhecker]

Same here and just below.

[zadjii-msft]

wait so if we find a hyperlink we marked up because it looked like a URL regex, we'll then look inside the autodetected one for a manually delimited one?

am I reading that right?