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

Debug Protocol: Allow passing back a path AND a sourceReference #60

Closed
roblourens opened this issue Sep 17, 2016 · 3 comments
Closed

Debug Protocol: Allow passing back a path AND a sourceReference #60

roblourens opened this issue Sep 17, 2016 · 3 comments
Assignees
Labels
feature-request Request for new features or functionality protocol change
Milestone

Comments

@roblourens
Copy link
Member

roblourens commented Sep 17, 2016

When using inlined sources from the sourceMap, the Node adapter passes a sourceReference, and keeps the mapped path in adapterData. I'd really like to surface this to the user, but if 'path' is set, then vscode tries to read the file off disk, fails, and shows an error message in the editor pane. When users have a weird source config, it would make it easier to find out what the SourceMap claims the path is, ie by hovering over the callstack frame or editor title, which makes it easier to find the fix. Putting it in the 'name' field doesn't look right as-is.

I think it would make sense for vscode to test whether the path exists, and if not, do a sourceRequest with the sourceReference.

But, maybe it's confusing to show a 'path' when that path doesn't exist. And in some cases it will be a URL or something which isn't a valid path.

Thoughts?

@roblourens roblourens added feature-request Request for new features or functionality protocol change labels Sep 17, 2016
@roblourens
Copy link
Member Author

roblourens commented Sep 17, 2016

Although honestly if we just showed a truncated string in the callstack when the name is too long (atm you have to resize the sidebar to be really wide until you see the path at all) then it might be ok to just put it in the name prop.

@weinand weinand self-assigned this Sep 19, 2016
@hbenl
Copy link
Contributor

hbenl commented Oct 20, 2016

I also see the need for a long and a short name for sources that don't correspond to local files.
What I'm currently doing is to extract the filename from the url for such a source (if a url exists) and put that in the name property. Now one of my users bemoaned that in his case this filename is not unique and he would like to have a way to see the full url.
For local files vscode shows the filename in the tab and the full path in a tooltip when the mouse hovers over the tab. I'd like to have the same user experience for sources that don't correspond to local files. This could be achieved by putting the url in the name property and let vscode shorten it for the tabs and the stacktrace. However I think that it would be better to let the adapter decide how the url should be shortened, so I vote for adding a "longName" or "sourceUrl" or whatever property to Source (and keep the "name" property for the short name).

@roblourens
Copy link
Member Author

This is allowed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality protocol change
Projects
None yet
Development

No branches or pull requests

3 participants