Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative paths sometimes not included as links in integrated terminal #22528

Closed
markwpearce opened this issue Mar 13, 2017 · 5 comments · Fixed by #22602
Closed

Relative paths sometimes not included as links in integrated terminal #22528

markwpearce opened this issue Mar 13, 2017 · 5 comments · Fixed by #22602
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug help wanted Issues identified as good community contribution opportunities terminal Integrated terminal issues verified Verification succeeded
Milestone

Comments

@markwpearce
Copy link

  • VSCode Version: 1.10.2
  • OS Version: Mac OSX (10.11.6)

Steps to Reproduce:

  1. Open VS Code integrated terminal
  2. Echo a relative path (eg. echo "src/app.js")

Description:

Let's say you have a build system that outputs a stack trace on a build error or failed test. If this was run from the integrated terminal, the file paths in the output should be included as clickable links which can be clicked to open the file in VSCode.

However, this only works if the path is either an absolute path (e.g. ~/work/project/src/app.js) or a relative path that begins with "./".

Many build systems and tools output file paths relative to the directory the command was run, without the leading "./", Karma for example. So the output would be something like: src/app.js, not ./src/app.js. The first is not matched by VSCode as an openable path, but the second is.

I believe that what is determined to be a path comes from the Regex in "terminalLinkHandler.ts"

Is there a reason why relative paths of this form (e.g. no leading "./") are not included?

@Tyriar
Copy link
Member

Tyriar commented Mar 13, 2017

The reason was because until 1.11 links aren't validated so there would be heaps of false positives. Performance was also a factor but it shouldn't impact that much really now that I think about it.

Now that links are validated maybe we should be more lenient when linkifying.

@Tyriar Tyriar added bug Issue identified by VS Code Team member as probable bug terminal Integrated terminal issues help wanted Issues identified as good community contribution opportunities labels Mar 13, 2017
@Tyriar Tyriar added this to the April 2017 milestone Mar 13, 2017
@Tyriar
Copy link
Member

Tyriar commented Mar 13, 2017

I'll assign this to April but if someone wants to do a PR before then you're welcome. You will need to:

  • Modify the regex to allow paths that are not qualified with ~/, ./, etc.
  • Make sure that the new path matcher does not conflict with previously matched links and does not create links with adjacent characters. Eg. we want to avoid this: ~/<a>link</a>

@markwpearce
Copy link
Author

Nice. I'll write a PR...

@Tyriar
Copy link
Member

Tyriar commented Mar 13, 2017

That would be awesome @markwpearce 👍

@Tyriar
Copy link
Member

Tyriar commented Mar 17, 2017

Fixed in #22602

@Tyriar Tyriar closed this as completed Mar 17, 2017
@michelkaporin michelkaporin added the verified Verification succeeded label Mar 30, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug help wanted Issues identified as good community contribution opportunities terminal Integrated terminal issues verified Verification succeeded
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants