Support links that point outside of the workspace (output pane)

[frankcai]

Text inside the output pane is only recognized as a link if it points to somewhere within the VSCode workspace. I have an extension that writes files to a temporary path and would like links to these to be clickable in the output pane.

[michelkaporin]

@isidorn sorry, not my area of expertise. This it in the output pane, where editor's link detection is used. Reassign me if you'd like me to look into it after I am done with link detection in debug console/exception widget.

[isidorn]

PRs welcome, code pointer https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/links/browser/links.ts#L323

[bpasero]

@Lixire @michelkaporin @isidorn can we revisit this? I see that there is a link detector pattern for the debug repl. Can we share the link detection from repl with the output link detector by moving it into a reusable helper?

There is a couple of reasons:

• I do not like the fact that the output editor only detects links for files inside the workspace
• we have many places of link detection that all seem related

Also, I see a questionable use of contextService.toResource that will no longer work when in a multi root environment where you will need to know for which folder resource the link belongs to. I filed #29190

[isidorn]

I am all up for revisiting this.
If interns are not interested for this please let me know and I will investigate.

[michelkaporin]

@bpasero I would love if we would use same utility for link detection. Currently we have own detector in every area (editor, repl & exception widget, terminal). Although I am not sure if I have enough time for this @isidorn.

We can try merging link detection between editor and repl with exception widget, but terminal will still handle links separately (see #24489).

[bpasero]

As far as I am concerned about the code we have in Output editor I think we should drop it in favour of what you have for the repl and exception widget. The output one is really bad because it only supports links for files that are inside the workspace. This probably dates back from the time we ran in the browser and did not want to show any links for any file outside of the workspace.

[Lixire]

I think I'll be kept busy with my task project for a while so if you want to investigate it right now then go for it. Otherwise, I can do it for the next iteration.

[michelkaporin]

@bpasero solution in repl and exception widget for link detection is also not the perfect one. We do not support http links, for instance, and it is quite complicated to introduce this support with the current regex. I'd prefer to redesign the solution, rather then reusing.

[Tyriar]

@michelkaporin maybe we should look into having a shared component between xterm.js and vscode? xterm.js doesn't have any non-dev dependencies right now but it would be good if all effort could be spent on the same solution. The terminal does support http links for example with a follow up item to use a proper parser for even better link detection xtermjs/xterm.js#583 (eg. "(http://some.com/link(2))" should exclude the outer brackets). /cc @parisk

In the end there is the common logic of finding the best substrings to turn into link(s) within a string, the actual application of those links may or may not be shareable (it's a relatively complex task for the terminal).

[parisk]

I am quite about introducing non-dev dependencies in xterm.js, because it forces us to keep it simple, lightweight and portable, which is important for browser consumers.

This is something that can always be discussed and reconsidered though 😄 . In any case, even if we decide to move with a non-dev dependency, this should not happen before 3.0.

[isidorn]

Duplicate of #34026