Defer bracket pair document parsing until it's actually used

[Tyriar]

Part of #161622

This change queues parsing of the document so that it does not block editor input latency. This is done via setImmediate such that it is called before any timers, the only downside to this is that changing a character adjacent to a bracket may appear white for a single frame.

This is a good trade off imo to save what I measured sometimes to be > 10% of the keypress event's runtime. The amount of time spent is quite variable, not sure why.

[Tyriar]

@alexdima can I not use set/clearImmediate in monaco?

Error: src/vs/editor/common/model/bracketPairsTextModelPart/bracketPairsTree/bracketPairsTree.ts(76,12): error TS233[9](https://github.com/microsoft/vscode/actions/runs/3276846488/jobs/5393380511#step:10:10): Property 'clearImmediate' does not exist on type 'Window & typeof globalThis'.
Error: src/vs/editor/common/model/bracketPairsTextModelPart/bracketPairsTree/bracketPairsTree.ts(123,31): error TS2339: Property 'setImmediate' does not exist on type 'Window & typeof globalThis'.

[alexdima]

can I not use set/clearImmediate in monaco?

Unfortunately setImmediate is out of the standards track and not available on the web. AFAIK it is deprecated and possibly only available in Electron/node.js

[Tyriar]

@alexdima good to know, will switch to timeout

[Tyriar]

This is where it happens now:

Probably better than immediate actually as immediate was happening before the animation frame

[Tyriar]

@hediet ready for a review, this has the changes @alexdima and I discussed which should ensure the state is correct when public APIs are called by flushing the queue at the last moment.

[Tyriar]

Adding @rebornix so I can get this in before endgame

[alexdima]

@Tyriar I would feel most comfortable if we can also get @hediet's review here, as he authored/owns that code.

out-of-date

[Tyriar]

@alexdima oh auto merge was enabled while I was typing. My thinking was he was already keen on the idea, just that it caused issues with the timeout. So merging now would make it in for testing and he could comment/revert if there is a problem with it.

[Tyriar]

I pinged @hediet about it to make sure he checks it out

[hediet]

The incremental bracket pair parser expects that the given edits precisely describe the changes between the state of the text model it saw the last time and the current state of the text model.
Queuing the changes and then processing them in the order they have been queued breaks this assumption, as the parser only sees the final state of the text model when processing these intermediate changes.

Imagine you start with this document:

}

Now the user

• (1) adds { at line 1, column 1
• (2) adds \n at line 1, column 1
• (3) adds x at line 3, column 2

This translates to these edits:

• (1) [{ start: (1:1), end: (1:1), newLength: (0:1) } ]
• (2) [{ start: (1:1), end: (1:1), newLength: (1:0) }]
• (3) [{ start: (3:2), end: (3:2), newLength: (0:1) }]

The state after (1) is:

{
}

The state after (2) is:

{
}

The state after (3) is:

{
}x

However, when the parser processes (1), it already sees the state (3).
The parser tries to reparse the text node at that position (line 1, column 1 to line 1, column 2) and still finds an empty line - thus the bracket tree is not touched.
Then it processes the \n and x insert changes and again does not touch the brackets 🐛

---

What would work though is to combine the changes, as we discussed some time ago (for precisely this problem).

In that case, you would only issue this edit:

• (1) [{ start: (1:1), end: (1:1), newLength: (1:1) }, { start: (2:2), end: (2:2), newLength: (0:1) }]

This would not only be correct, but also more performant, as the parser only needs to do one pass.

However, combining changes is not entirely trivial: You have to describe later changes in terms of the initial situation. This should be doable in linear time though.