-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
Link detection for the exception widget and debug console #24451
Link detection for the exception widget and debug console #24451
Conversation
…scode into exception-link-detection
@michelkaporin, thanks for your PR! By analyzing the history of the files in this pull request, we identified @egamma and @bpasero to be potential reviewers. |
Awesome! Did you test this with stack traces printed by mocha (relative paths)? |
@felixfbecker Thank you :) I did not explicitly test mocha but those mocha stack traces described in #15760 should be picked up now (see the the sample image above which is a super set of what was outputted there). The things that won't work currently:
I plan to tackle those things in a separate issues. |
I don't see this explicitely in the image above, will it work for relative paths that do not take up a whole line? Eg
right now that only highlights |
@felixfbecker yes, it will work for relative paths that do not take up a whole line. |
@michelkaporin I appologize for the slow response was busy around the release. Just checked the PR, looks great! After discussing with @bpasero we agreed that doing a FS stat to figure out if something is a relative link is too heavy for a simple operation like this. How precise would the relative path mathching be if you can not verify it against the real file system? If not very precise then we should not support relative file matching. |
I think it should be doable to detect relative links without a stat. If spaces in paths are not to be supported, it's trivial. Otherwise you would need to have to look at common seperators like parenthesis. But please please keep relative link detection, I need to click on these >100 times a day in stack traces. |
@isidorn Ok, I can drop link validation and try to match it with regex then. |
Thanks for letting me know, we should also not use |
@michelkaporin @isidorn @bpasero I disagree that we shouldn't stat the files. Without Related:
|
Stating things we "think" are links is crazy to put it in simple words (keep in mind that people work in environments with network drives where a stat might not be as fast as on your SSD disk). Since output is unbounded this could easily cause tons of disk access for no helpful reason. A link should be detected without going to disk and it is totally fine to have false positives (e.g. it is OK to not be 100% correct). Once the user clicks on a link, it is fine to show an error if the file does not exist. |
@bpasero to be more specific the terminal stuff is using Is it so bad to check the existence of a handful of paths after a terminal command is run (or when the user scrolls the terminal)? |
I would not do it, the output panel has never done it. There are tons of regexes that try to detect links and render them optimistically. What is wrong with that approach? |
Tracking stat in terminal links in #25024 |
@isidorn I have updated regex to be more precise without Exception widget is an example of high false positive rate with file names coming from debug adapter, that are detected by regex as workspace' relative links, whereas they are not, in reality. On the good side the user will get an 'Unable to open' message, when clicking on such links. |
// group 3: line number | ||
// group 4: column number | ||
// eg: at Context.<anonymous> (c:\Users\someone\Desktop\mocha-runner\test\test.js:26:11) | ||
/(?![\(])(?:file:\/\/)?((?:([a-zA-Z]+:)|[^\(\)<>\'\"\[\]:\s]+)(?:[\\/][^\(\)<>\'\"\[\]:]*)?\.[a-zA-Z]+[0-9]*):(\d+)(?::(\d+))?/g |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice that the comments are the same but the regex is now more complicated.
Could you please add some comments in code to clarify this regex beast
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@isidorn I've added more comments, hope it makes things more clear. It is quite big just because it tries not to match lots of special characters. In the end we still plan to move away from it to the common regex between terminal, debug console and exception widget.
// noop | ||
} | ||
|
||
public handleLinks(text: string): HTMLElement | string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand there have been no changes till the end of this file, it has just been moved over.
If that is the case it looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@isidorn It was changed to handle multiple links in the provided string. Previously it used to detect only first link match and then stopped.
) { | ||
// noop | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this handleLinks
is now a public method we could try to make the API a bit nicer, a personally find it ugly that it returns an HTMLElement
or a string
. It is hard to figure out what to expect as a return result for someobdy who just wants to use the link detector.
At least provide some comments to clarify each case, or try to always return an object with the corresponding fields.
For ideas you can also check what does the terminal / editor link detector do and how does their API look like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@isidorn I've added the comment to it. I hope this explains it well.
If you have any suggestions on what should be a return result instead, I am happy to hear. Currently it perfectly suits exception widget and debug console needs.
@@ -27,6 +27,11 @@ | |||
margin-top: 0.5em; | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
@@ -7,13 +7,10 @@ import * as nls from 'vs/nls'; | |||
import { TPromise } from 'vs/base/common/winjs.base'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall and I like we removed code from this class.
I only have the issue that you are creating a linkDetector
at every iteration in a loop. Would it not make sense just to create one global one for the replViewer and always to reuse it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@isidorn You're right, did not see that for-loop when refactored. I've moved LinkDetector instantiation to the constructor.
@@ -11,9 +11,11 @@ import { ICodeEditor } from 'vs/editor/browser/editorBrowser'; | |||
import { IContextViewService } from 'vs/platform/contextview/browser/contextView'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
@michelkaporin great work. I have added some comments directly in the code. Once you adrress them we can merge it in. |
…ut. Corrected regex description.
…scode into exception-link-detection
@isidorn thank you! I've addressed all your comments, please see my replies. The build is passing locally, AppVeyour succeeds also on the latest codebase. Cannot find any build issues in the Travis log that are to do with my changes. |
@michelkaporin looks good, let's merge it in to see how it behaves :) |
Partially reused regex of the reverted PR by @felixfbecker, credits to you!
Fixes #15760, #17085 (and all its ancestors).
Partially implements #21349.