html-language-features: text document provider support for customData.html #137557
Conversation
|
|
| return { | ||
| get uris() { | ||
| return pathsInWorkspace.concat(pathsInExtensions); |
There was a problem hiding this comment.
what's the benefit of that change?
There was a problem hiding this comment.
I converted the path path lists in to Set so the check in line 31 becomes as fast as possible.
With the change, checking of a path has changed should be O(1) but returning the list has higher complexity.
If we want to have a Set to track the paths and avoid having to flatten it to an array in the getter get uris() we would need to maintain both a set and an array in parallel. One for filtering paths and one to return it. I can change that if you want to. If it makes sense also depends a bit on how often the getter is invoked, but I guess we don't know that..
| @@ -20,34 +22,34 @@ export namespace FsReadDirRequest { | |||
|
|
|||
| export function serveFileSystemRequests(client: CommonLanguageClient, runtime: Runtime, subscriptions: { dispose(): any }[]) { | |||
| subscriptions.push(client.onRequest(FsContentRequest.type, (param: { uri: string; encoding?: string; }) => { | |||
| const uri = Uri.parse(param.uri); | |||
| if (uri.scheme === 'file') { | |||
| const uri = param.uri.match(uriScheme); | |||
There was a problem hiding this comment.
Based on earlier comments I thought Uri.parse shall explicitly NOT be used to check for schemes.
I actually actually liked it better before but it feels a bit inconsistent to use sometimes use a bare regex and sometimes use Uri.parse. Don't have a string opinion here. I can change it back. Lat me know what you prefer.
One more important thing:
The serveFileSystemRequests(..) helper was already in the code, I did not create it.
However, it was unused - so someone had written that helper but never activated it (or deactivated it for some reason).
I just activated added in client.onReady() in htmlClient.ts (same way it is done in css-language-features where pretty much the same code has been active all along).
Was there a reason why these handlers were added but commented out? Seems a bit suspicious..
There was a problem hiding this comment.
uti is always in the URI format. So Uri.parse is ok to use.
The point is to no use Uri.parse on a relative path.
| if (uri.scheme === 'file') { | ||
| // only resolve file paths relative to extension | ||
| if (!uriScheme.test(rp)) { | ||
| // no schame -> resolve relative to extension |
|
I made some polish changes (and reverted the requestService change), so this looks all good now. The missing |
|
@sijakret Thanks for all the work! |
|
@aeschli something got lost! sijakret@f1455ea#diff-35b696cf6cdc005ac94347afd4160dbae29c3a336d5ce690501bbd67ec6fddbcL35 Edit: I have created another small PR with a fix: #137980 |
…r/virtual-doc-support html-language-features: text document provider support for customData.html
This PR implements #135459
It adds the ability for for html-language-features extension to receive custom-data via Text Document Provider and update on changes to these documents.
With the change extensions can provide contribute dynamic data via
customData.html;