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

Checks integrated terminal output for more types of relative paths #22602

Merged
merged 3 commits into from Mar 17, 2017

Conversation

markwpearce
Copy link

@markwpearce markwpearce commented Mar 14, 2017

Integrated terminal output is now checked for relative paths of the format src/app/file.ts, that is, relative paths without a leading ./

These types of relative paths are checked to make sure the file they are referring to actually exists.

Some tests were added to verify the paths are properly formatted in order to check for the file.

Note: This was not tested in a Windows environment

Fixes #22528

@mention-bot
Copy link

@markwpearce, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Tyriar to be a potential reviewer.

@msftclas
Copy link

@markwpearce,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.

It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

@msftclas
Copy link

@markwpearce, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.

Thanks, Microsoft Pull Request Bot

Copy link
Member

@Tyriar Tyriar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @markwpearce, this is great. I made some initial comments but I haven't played around with it yet.

@@ -41,6 +65,7 @@ suite('Workbench - TerminalLinkHandler', () => {
testLink('c:/a/long/path');
testLink('c:\\a\\long\\path');
testLink('c:\\mixed/slash\\path');
testLink('a/relative/path');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this also linkify just plain words for example "foo"? That way after validation the output of ls should all be linked. If so a test for that would be great.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it should. I'll add a test.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually now that I think about it that's probably not a good idea until we know more about the current working directory within the terminal. It could get confusing otherwise. Right now wealways open files relative to VS Code's folder, not the terminal's.

}

private _resolvePath(link: string): TPromise<string> {
link = this._preprocessPath(link);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this factoring out purely for code cleanliness?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly to to test link preprocessing (_preprocessPath() method) in isolation, and not have to worry about it returning a promise in the tests.

@Tyriar Tyriar added this to the March 2017 milestone Mar 14, 2017
@markwpearce
Copy link
Author

markwpearce commented Mar 15, 2017

I've noticed three issues in this PR:

  1. (easy fix) in _preprocessPath(), it tests for a workspace via this._contextService.hasWorkspace, but this is a function, so it should be called (ie. this._contextService.hasWorkspace())
  2. This currently only matches files with at least one path separator, so it won't match relative files in the SAME directory...
  3. Linkifier (in xterm) only allows 1 match per row of text... so if you were to do something like:
    echo "src/app.js src/index.html" only src/app.js would get linked :( This leads to the problem that if we do look for any valid file name and the text output is: ERROR: file.ext Linkifier gets a match at "ERROR" (since that is a valid file name), and won't look further down the row, even though the thing that is actually important to us is later.

Given that 3 is a bigger problem than 2, I'll solve issue 1 for now, and to be links, outputted file paths will just need to have a path separator in them.

@Tyriar
Copy link
Member

Tyriar commented Mar 17, 2017

@markwpearce on point 3, this is actually a bug in xterm.js thanks for finding it. The intent was to linkify multiple links on the same row using a single link matcher, created xtermjs/xterm.js#612

Copy link
Member

@Tyriar Tyriar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really high quality PR @markwpearce thanks! I created a follow up to do it for paths with no separator.

} else {
// Resolve workspace path . / .. -> <path>/. / <path/..
if (link.charAt(0) === '.') {
if (!this._contextService.hasWorkspace) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch 👍

@Tyriar Tyriar merged commit 8176224 into microsoft:master Mar 17, 2017
@github-actions github-actions bot locked and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Relative paths sometimes not included as links in integrated terminal
4 participants