The current language in a region of code is known to the UI thread (renderer process) of VS Code because it comes in via tokenization, and tokenization is executed on the renderer process. All vscode read APIs are synchronous, for example getting the current active text editor, reading its selection, reading its text, etc. If we would want to add tokens API to vscode, we would have to make that API synchronous.

But in order for the API to be synchronous, we would need to have the tokens readily available to give out to extensions. So we would either have to tokenize on the extension host and produce those tokens synchronously in the event loop of the extension host, or we would need to send those tokens eagerly from the renderer process to the extension host just in case there might be an extension that would want to read them. Neither option is good, tokenizing on the extension host would just freeze the event loop of the extension host for a long time, sending the tokens from the renderer process would cause significant CPU usage on the renderer to compute diffs and send them all the time to the extension host. To make matters worse, all of that might have been for nothing, as there might be no extensions interested in those tokens in the extension host or even if there would be an interested extension, maybe it would not need to read them all the time.

The other option would be to make the read API and diverge from the common practice of having read APIs sync. But let's analyze what the problem of that would be: it is possible that by the time the API returns, the buffer changed and the result might not reflect the state when the request was made, nor the state when the request was completed. The result might reflect an intermediate state, as the result is not synchronized in any way with the text document state. Here is a sketch of the problem:

// this lineText now captures the text of line 6 at `s1`
const lineText = document.lineAt(6); 

// by the time the request reaches the renderer thread and returns, it is possible that
// the text document was changed in the meantime. To make matters worse,
// the response to this request is not synchronized in any way with the text document
// change event, so the response might not even represent the state of the text document
// when the response completes.
// i.e. lineTokens now captures the tokens of line 6 at `s2`.
const lineTokens = await document.tokensAt(6); 

// but the document could be at `s3` at this point
const lineTextAgain = document.lineAt(6);

So IMHO we don't have any decent options. And that is why we don't have tokens API on the extension host.

Emmet JSX HTML abbreviations suggested inside style tag #119736

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Emmet JSX HTML abbreviations suggested inside `style` tag #119736