Add support for OSC 8, Hyperlink, to the console infrastructure

[stuaxo]

There is a new ansi code for hyperlinks in the console.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

It would be great if this was possible in the windows console.

[arcanis]

If it helps prioritising this feature, I'd like to use it to implement better error messages in Yarn: the package names would be clickable and point to the package websites.

[lypanov]

Could MSFT please comment on if this is possible for us to work on? As in, is this something that can be done only from the OSS side or will it also require changes to ConPTY in Windows itself? I find the architecture quite difficult to grok.

[zadjii-msft]

This is definitely something the community could work on - ConPTY is OSS too (in this repo 😉). I'd say it's probably not something a community member would want to just pick up - it would take a lot of changes. We'd need to change the TextBuffer to recognize where URLs are in the buffer. We'd need to probably change the Renderer and IRenderData interfaces to support rendering where a hyperlink is. Then, there'd probably need to be changes in the InteractivityWin32 project to support clicking the links. And this is all just for conhost.exe. To add it to the Terminal, you'd probably need to change TermControl instead of InteractivityWin32.

After I typed this up, it actually doesn't sound as bad as I thought initially.

Fortunately, I don't think there's any conpty changes necessary here 😄

DISREGARD THAT. I thought I was commenting in #574. This issue's a little different.

For conhost to support this VT sequence:

1. update OutputStateMachineEngine to support parsing this sequence
2. Add support to TextBuffer to know when a region of text is a hyperlink, and what the URL is for that region.
3. Add functions to AdaptDispatch, ConGetSet, OutputStream, getset.cpp, etc. to add/remove hyperlinks from the buffer
4. Add code in Renderer, RenderData to be able to identify when a region of text should be rendered as a hyperlink.
5. Modify GdiEngine to be able to draw hyperlinks (and possibly stub out other renderers as well. The VtEngine should probably just emit the text)
6. Modify InteractivityWin32 to check if a click is on a hyperlink in the buffer, and open the browser (or ShellExecute) when it is

Then for the Terminal, after 4 (but not needing 3/5/6):
7. Modify OutputStateMachineEngine to not only handle hyperlink VT sequences, but also pass them through to the terminal
8. Add support to TerminalDispatch to add/remove hyperlinks from the buffer
9. Modify DxEngine to be able to draw hyperlinks
10. Modify TermControl to check if a click is on a hyperlink in the buffer, and open the browser (or ShellExecute) when it is

[lypanov]

Mike Griese (@zadjii-msft) My current specific interest could reduce this list even further. I'd like to add support for the OSC hyperlink extension to the wezterm (https://github.com/wez/wezterm) Windows port.

Reading over the changes from https://github.com/microsoft/terminal/pull/891/commits to add support for OSC 10/11 sounds like it has direct parallels in the changes I'll need for OSC 8.

I understand from the maintainer of wezterm that the VT sequences themselves are not directly passed on to wezterm. Is this due to the lack of "parse and re-emit" support in this repository? Am I correct in saying that OutputStateMachineEngine would be the correct place to add such support to? Is this source file part of "conhost"? I've read the sentence "pass them through to the terminal" here from you and also several times in the docs but don't understand exactly how this can relate to 3rd party users of ConPTY.

Final question... how can wezterm know about my changes to conhost? Do I have to somehow embed the open source fork? (My assumption is that wezterm right now is using a conhost provided by Windows 10).

Please correct any horrible assumptions / failures in understanding I might have. Thank you so much!