Scenario: Add support for hyperlinks

[zadjii-msft]

This is the the megathread for tracking all the remaining work that needs to be done for hyperlink support in Terminal.

"Soon" Timeframe

• Original issue: Add support for OSC 8, Hyperlink, to the console infrastructure #204 -> added in OSC 8 support for conhost and terminal #7251
• Allow file:// URIs -> added in Support the "file" URI scheme #7526
• [DISCUSSION] Allow more URI schemes #7562 Allow other URI schemes
• Render hyperlinks differently from regular text in Terminal -> added in Display URI tooltip, render dashed/solid underline for links #7420
• Hover underline text that have the same hyperlink ID and display the URI -> added in Display URI tooltip, render dashed/solid underline for links #7420
• Display a content dialog box for URIs we cannot parse/schemes we do not support -> added in Open up content dialogs for invalid URIs and unsupported schemes #7523
• Design Clickable Links & Link preview feature/extension #574 Add support for Terminal to auto-detect hyperlinks -> added in Add support for autodetecting URLs and making hyperlinks #7691
• Change pointer when hovering over a link #7563 Switch the pointer to the 👆 icon when we're hovering a link (in the clickable state, like with ctrl pressed)
• VtEngine::_SetHyperlink uses fmt::format to render the hyperlinks, and it should really use _WriteFormattedString
• Add hyperlink support to conhost #7564 Hook up hyperlinks to conhost (rendering + clicking)
• Include hyperlinks in HTML copy #7565 Make sure hyperlinks are included in HTML copy
• Only underline hyperlinks on hover #8123 Only underline hyperlinks on hover -> added in Make the link underline less obtrusive; don't use it for pattern #8148
• Controlling tooltip delay for URLs Controlling tooltip delay for URLs #8242
  • Abandoned, platform limitation
• Add a setting to disable auto detection of links (in PR v1.4.3141.0 show Windows Terminal (Preview) when right clicked on Task Bar #8239)
  • Abandoned, we're not sure anyone actually ever wanted this
• Links/URLs get offset when certain unicode characters are printed Links/URLs get offset when certain unicode characters are printed #8709
• URL hover doesn't work when VT mouse mode is enabled #9117
• Keyboard navigation of clickable link #6649
• IPv6 links can not be Ctrl+Clicked #11901

Backlog

• Add a setting to configure the regex used to detect patterns
• Allow "hyperlink" matching for arbitrary patterns and adding custom handlers  #8849
  • Theoretically, this could supersede [DISCUSSION] Allow more URI schemes #7562
  • Should be self-consistent with Add a setting to configure display of auto detected links, normally and on hover #8294
• Control the styling of hyperlinks - attributes used for autodetected hyperlinks, and then different attributes for hovered ones Add a setting to configure display of auto detected links, normally and on hover #8294
• Feature Request: link generation for files + other data types #2671

References

• This VsCode issue has an enormous set of references to improvements they've made: Test: Terminal link improvements vscode#172084
• Spec for Triggers and Custom Clickable Links #15700

[DHowett]

Proposed order of attack:

• Hover tooltip
• Rendering -- possibly simple rendering w/ a new underline style for me?
• Take a break, regroup, think about the design for autodetection
• (possibly work on other things in the meantime)
• Autodetection

[zadjii-msft]

Hey so hover tooltip might be hard - we can't embed a webview, so doing something like

Might be especially hard. But we could start with a TeachingTip sytle one for now

Unless we could somehow pre-render a web page to an image and display that in the tooltip. Or use something like the "social" image from github (though I haven't the damndest clue how that works.)

Maybe we should just start with

Open [web page | file]: 
{url}

in the tooltip

[DHowett]

Yeah i definitely think tooltip and “the link preview from the video” are different workitems that we should tackle separately :)

[j4james]

If you have to have a "link preview", I'd recommend something really basic based on the page meta data (like the meta title and description, and maybe a favicon and/or og:image). But as cool as this might seem, I don't think it's practical for a hover effect given the delay needed to download and render these things (unless you're pre-rendering the previews, which sounds like a really bad idea).

Which brings me to the main problem. Even if you're only connecting to the site on hover, that still seems inadvisable. When I'm using a terminal I really wouldn't expect it to be making internet connections without my consent. So this feature would definitely have to be optional, and arguably I think should be off by default.

I'm possibly a little biased here, because my internet connection is metered to a certain extent. But even if that weren't the case, would most people be comfortable with their terminal downloading unknown webpages in the background?

[DHowett]

Yeah, I definitely don't think that "fetch any link I hover over" is something we should ship in core or opt-in by default. It makes for a really compelling video because it shows how modern and flashy we are, but it's too much of a disclosure and safety risk to put right into our project.

[jzabroski]

• Allow mailto: URIs

Would this be RFC conforming 😒 mailto: URL, or 😍 mailto: URL that allows multiple email addresses?

[DHowett]

Generally, "whatever type of thing is supported by the registered protocol handler" ;P

[jantari]

I don't know whether this has been considered already, but when doing a rich-text copy of the terminal buffer the hyperlinks should probably be preserved on paste

[DHowett]

Thanks @jantari! Just added that to the main scenario body.

[giggio]

I just built the latest commit, but it can't parse an url, you have to use the escape sequences. Is this use case planned:

echo 'Hello from Windows Terminal: https://github.com/microsoft/terminal/'

And then click on the link and it opens?

[DHowett]

to be fair, mailto isn’t traditionally followed by // as it does not designate a path. We have issues tracking both “let me customize the URL regex” and “expand protocol support.”

So that’s the plan.

[KalleOlaviNiemitalo]

@vefatica, in v1.7.572.0, TerminalPage::_IsUriSupported allows only http, https, and file. Other URI schemes have been discussed in #7562.

[vefatica]

What about ftp://? ... not supported? Yet it gets underlined and a popup tip.

I can't remember way back but in recent decades I've always used mailto://. ShellExecuteEx doesn't mind

[KalleOlaviNiemitalo]

According to #7691 (comment), ftp: hyperlinks were going to be unblocked "shortly"; but almost five months have passed already. The regex in v1.7.572.0:

terminal/src/cascadia/TerminalCore/Terminal.cpp

Line 87 in 89c9e6d

std::wstring_view linkPattern{ LR"(\b(https?|ftp|file)://[-A-Za-z0-9+&@#/%?=~_|$!:,.;]*[A-Za-z0-9+&@#/%=~_|$])" };

[heaths]

file:// links with \\wsl$ yield an error dialog despite working as-is from the Windows Run dialog. I opened #10188 to track, unless you wanted to keep this issue as an evergreen source of outstanding issues.

[phil-blain]

Hi! I'd like to be able to configure the web browser used to open hyperlinks, but just for Windows Terminal (not OS-wide). I couldn't find an open issue about that, should I open a feature request ? :) Thanks for working on such a nice app!

[zadjii-msft]

@phil-blain From #9491

I'd rather not get us into the business of launching specific applications for URLs specifically. Once we add configurable pattern detection and matching (which is on the backlog somewhere), we'll also add pattern execution. That'll let folks customize which browser launches for which patterns.

see #8849

[ironyman]

@zadjii-msft
Just wondering, how hard would it be to let console applications emit hyperlinked text? E.g. if dir could output hyperlinked file names which are clickable and launches the files that would be pretty cool. Like the Symbolics Genera terminals https://www.youtube.com/watch?v=o4-YnLpLgtk

[lucy]

@ironyman
You can already do this with OSC 8 (https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda) which Windows Terminal supports AFAIK.

[zadjii-msft]

So yes and no. Apps can print hyperlinks, for sure, easily today with OSC8 as mentioned above. Now, there's definitely limitations here. The OSC8 spec specifically calls out files in this section, though, I don't think we support file:// URIs quite yet. There's complicated reasons for that, which are probably mentioned in # NEVERMIND I was wrong. See #7526. Neato!

Then there's always the issue of updating the utilities to make use of that sequence. Updating the dir in cmd is pretty much off the table, but PowerShell's gci might have more luck.

[heaths]

I don't think we support file:// URIs quite yet. There's complicated reasons for that, which are probably mentioned in # NEVERMIND I was wrong. See #7526. Neato!

Though, #10188 still means they don't work for WSL URIs. 😉

[ironyman]

Thank you @lucy I didn't know that command existed. That addresses one issue!

@zadjii-msft clickable sendInput is a really good idea. I imagine it would be very useful after say running git branch, then you could click on one of the branches and terminal would fill the input prompt with git checkout (branch name). That would be super cool.

Although what if you don't want to checkout but rather you want to delete the branch? Is there an easy way to give the user a list of options?

[zadjii-msft]

@ironyman That's definitely an interesting idea. We're absolutely in the realm of hypotheticals now. Click-to-sendInput isn't an existing paradigm, so I suppose we can come up with whatever we want. What would that UX be like?

Would it be something like:
>

---

Since I'm keeping notes here:

clickable sendInput

ee80820

dev/migrie/fhl-clickable-send-input

[jantari]

I think the particular scenario you're discussing (suggesting branch names) is better served by tab-completion.

But, for other scenarios or if mouse-interaction is really really wanted then console-apps can already receive and process mouse input (see INPUT_RECORD struct). I feel like it is best left to application developers to create either git-clients or tab-completion engines that implement mouse-support application-side. I don't think it is something the terminal needs to get (even more) involved in, unless there is a recognized VT standard for it we don't support but I haven't heard of any.

[KalleOlaviNiemitalo]

Click-to-sendInput seems rather error-prone because the software that outputs the clickable text does not know which software will eventually read the input, or what else will already be in the input buffer.

Alternatively, clicking the text could copy an application-specified string to the clipboard (or display a menu of such strings), and the user could then separately paste it where desired (respecting the bracketed paste mode). This would not allow the string to contain function-key events or similar.

Alternatively, clicking the text could send a Windows Terminal specific event with an application-defined (Base64?) payload, and the receiving application could then decide whether to run it as a command or insert as text. This however would require changes in shells in order to handle such events.

[KindDragon]

Would it be something like:

Looks similar to https://fig.io. I would love to see it on Windows

[ironyman]

I think the particular scenario you're discussing (suggesting branch names) is better served by tab-completion.

But, for other scenarios or if mouse-interaction is really really wanted then console-apps can already receive and process mouse input (see INPUT_RECORD struct). I feel like it is best left to application developers to create either git-clients or tab-completion engines that implement mouse-support application-side. I don't think it is something the terminal needs to get (even more) involved in, unless there is a recognized VT standard for it we don't support but I haven't heard of any.

I think tab completion is good for people that already know what commands they want to use but for beginners it would be helpful to have the relevant commands presented to them when the context appears.

It's also more convenient to click on a menu item even if you could type it sometimes because it's faster. If you're familiar with windbg, it has a CLI environment where some commands output clickable text that executes commands in appropriate situations.

Regarding your second point, I think it's hard to leave everything to app developer and the terminal has to help out here because in git, it will print something and exit so it can't handle clicks. That means you need a git-client of some sort but that's a lot of work. It's much easier to let git output clickable text that fills the terminal's input prompt for the next git command.

@zadjii-msft I think that would be perfect!

[SeeminglyScience]

WinDbg's console is a good showcase of how useful "click to send input" could be.

In the screenshot the first command was typed manually. The second command was processed automatically by clicking the second link (next to MethodTable). I think PowerShell (and probably everything else really) could use this type of feature extensively in object formatting to greatly improve workflow, especially for newer folks.

[KalleOlaviNiemitalo]

The security needs of the debugger are different because the extensions that output DML are loaded and trusted by the debugger engine.

For the PowerShell scenario, if WT sent a custom event, then PSReadLine could recognise that. It would work as well as allowing arbitrary sendinput, perhaps even better because the event handler could stash the line that is being edited and restore it afterwards.