microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.46k stars 8.31k forks source link

Improve `file://` hyperlinks support - local/remote hostname #14116

Open ltrzesniewski opened 2 years ago

ltrzesniewski commented 2 years ago

Description of the new feature/enhancement

Currently, Windows Terminal supports the following file:// URI patterns:

The following patterns are rejected with a "This link type is currently not supported" message:

Please add support for these cases. Note that the hyperlinks (OSC 8) spec requests for the hostname to be present in file URIs.

Proposed technical implementation details

The following justification is provided in the code:

https://github.com/microsoft/terminal/blob/54dc2c4432857919a6a87682a09bca06608155ed/src/cascadia/TerminalApp/TerminalPage.cpp#L2304-L2309

After testing with ShellExecuteEx (more precisely with Process.Start with UseShellExecute in .NET), I noticed the following:

Therefore, I think the Windows Terminal should:


This relates to #7699 and #5001.

See also the discussion in https://github.com/BurntSushi/ripgrep/issues/665 for the problems this feature would solve.

Another example of a really useful usage this would enable would be oh-my-posh WSL links:

image

ltrzesniewski commented 2 years ago

As a bonus point, if Windows Terminal could also strip the fragment #xxx and query ?xxx parts of a file:// URI, that would be helpful for interoperability.

The Windows shell cannot handle those, but other terminals may use them for opening a text file at a given line for instance (e.g. kitty will interpret a #42 fragment as a line number). It would be nice if those links could work in WT as well, although with more limited functionality.

See the drama in https://github.com/BurntSushi/ripgrep/pull/2322 if you want more context.

zadjii commented 2 years ago

I also have thoughts on the matter as it relates to the pattern matching spec in progress (for after paternity leave)

ShayBox commented 1 year ago

This may be unrelated, I'm not sure

Web browsers, other programs, and terminals already allow for custom protocols registered by applications, for example: mailto:// skype:// curseforge:// vrcx:// etc

Why not expand Windows Terminal to support them? Probably with a trust prompt, similar to VSCodes workspace trust or Discords link trust.

j4james commented 1 year ago

@ShayBox Support for additional protocols was tracked in #7562, and was addressed by PR #14993, although that update hasn't been released yet.

ltrzesniewski commented 1 year ago

What happened to the monthly releases? 😢

zadjii-msft commented 1 year ago

@ltrzesniewski Monthly releases are a little easier when we're not entirely rewriting the process model of the Terminal (#5000) or entirely re-rewriting the rendering stack (#14959). Those two changes in particular took quite a bit longer to validate.

ltrzesniewski commented 1 year ago

@zadjii-msft That explains a lot of things, thanks for pointing it out! 🙂

DHowett commented 1 year ago

I didn't intend to let this one marinate for so long. After reading it initially, I let it grow into this huge and concerning feature request... but it really isn't that.

This is in line with the work we need to do to polish up hyperlinks in #8849. I'll keep it separate for now, but it's along the path we'll need to take to differentiate what we (1) detect and (2) launch and make those configurable.

Diti commented 1 month ago

The hyperlinks produced by eza (with eza --hyperlink /var/tmp for instance) in WSL also don’t work. Windows Terminal doesn’t seem to be aware it is in a WSL session and won’t transform the links to something like file://wsl$/WLinux/var/tmp. So clicking on the “regular” links have no effects.