getTokenInformationAtPosition API causes too much traffic and blocks the renderer process
#99356
Comments
|
Using the file above with 2261 links, saved as
These are totals of 2261 individual calls to Things that we can do in May
|
jrieken
added
api
tokenization
|
I like the "limit issue link detection to the first N occurrences", where N is 20. It seems unlikely that folks will have more than 20 issue references in a file, and they can still get to a link via the hover if they want. |
…s the renderer process Part of microsoft/vscode#99356
|
|
@alexr00 The API itself will check the version before and after the roundtrip, so all it should take is collecting all requests and firing them at once. |
|
Sorry @alexr00 I don't believe this is a feature request? Can you please reassess the issue type? |
alexr00
added
bug
|
Sorry about that. I have no recollection of making this a feature-request. |
ghost
mentioned this issue
|
@alexr00 I am planning on removing this proposal and we need to find an alternative for your use-case. Assuming it is still needed. Most extensions that need token information load vscode-textmate but your case might be simpler and you can do some pragmatic detection of comments (which I believe is needed here) which us expose the language configurations |
|
Actually, this is very much still used. Will there be a new mechanism for this before the removal? |
|
GHPRI uses this API to make sure we don't show completion suggestions for issue numbers and users outside of comments, which is essential for the issue and user completion feature. It becomes too noisy when completions are offered outside of comments. |
Sorry, but you will have to invent your own mechanism, like re-use vscode-textmate or do some pragmatic detection of comments |
|
@jrieken I should be able to add a reasonable guess about whether there is a comment using the language configuration as you suggested. Would you consider API to expose the language configuration? |
|
Sure, we can add |
idk - but given the past discussions I would say that it should by sync, e.g be pushing new language configurations by the 1 The API for |
|
We load language configuration files on demand, when tokenization encounters a language or when a file with the language is opened. The problem with a sync implementation for
|
|
Cann't we do it incrementally and send an update/event whenever new language config is encountered? We do something similar with word definitions here |
|
👍 Yes, word definitions are pushed as they are encountered, but the word definitions are only used internally when calling a specific method But we don't have a method |
I was thinking of some kind of |
I have been trying to do exactly that but I can't compile native node modules in |
|
I have done a huge amount of legwork on this in the past few months. I have a PR coming that will make this API method both fast, useful, platform-independent and performant A key benefit is that documents can be tokenized from the grammar contributed by a registered extension. We are obtaining the precise results that VS Code end users see in the UI. Subscribe to vsce-toolroom/vscode-textmate-languageservice#22 to follow my progress :) PS: Main delay is that I always automate passing tests before release. |
Webpack solved the issue - and allowed for a browser friendly release that ships deps too 🤾🏾♂️💯 |
|
This has been implemented with tests and will ship in a 2.0.0 release either today or tomorrow. |
|
https://github.com/vsce-toolroom/vscode-textmate-languageservice/releases/tag/v2.0.0
|
and others
GitHub Pull Request Nightly BuildPreviewTry to work in the file and observe how the window is not really responsive.
Add a console log statement here --
vscode/src/vs/workbench/api/browser/mainThreadLanguages.ts
Line 47 in 353e8f4
Observe how after each keystroke there are thousands of requests going from the extension host to the renderer process.
The text was updated successfully, but these errors were encountered: