Cannot get Decorations for a textEditor

[ryanluker]

• VSCode api version: 1.1.10
• OS Version: Linux

Steps to Reproduce:

1. Render decorations with textEditor.setDecorations
2. Try to find current decorations with textEditor.getDecorations but it doesnt exist?

Background:

I am looking at adding true e2e tests for my vscode extension
ryanluker/vscode-coverage-gutters@3af53e0#diff-579bc502e2c0744db6d55afe38b9f3d9R14
but there doesnt seem to be a way to see the current decorations?

Based on some internet searching I couldnt find anyone else doing this level of e2e testing (correct me if I am wrong and or if there is examples in the vscode project itself for this), so this issue would probably be more of a feature request to add a new piece of functionality to get decorations? I have a feeling the lack of getDecorations might be for security / performance reasons but I am happy to be wrong in this 😃 .

[alexdima]

The root cause is performance. We don't want to sync back all those (potentially thousands) of decorations back on each keystroke for the (slightly unlikely) case someone might want to read them.

[ryanluker]

@alexandrudima thanks for the reply! Yes I was thinking that might have been the case... I have other ways of exposing / accessing the relevant details so I will take a look at using that.

[DanTup]

@alexandrudima Is there any other way we can get the the updated range for a decoration as the user modified the document? Eg., let's say I apply a decoration to a line of code and then the user inserts a newline before it - is there any way I can find the new range of that decoration?

[alexdima]

@DanTup Sorry, there is no way.

[DanTup]

@alexandrudima Thanks for confirming. For now, I'm keeping track of the ranges myself and subscribing to onDidChangeTextDocument and then updating my ranges based on the changes being made. It's kinda clunky, but seems to work (as long as the user doesn't edit the file outside of Code, then things will fail).

I'm not sure whether to raise a feature request for better handling of this (really what I'd love is to be able to attach metadata to a random range of code and let Code track it for me) because I suspect not many extensions will need to do this kind of thing.

[alexdima]

We can use this issue to track the feature request. The problem is that 99% of decorations are computable from the text itself. e.g. bracket coloring, link underlines, squiggles, find matches, etc.

So, in 99% of cases there is no need to read the tracked decorations. And the challenge is how to cover the 1% case where tracked decorations cannot be recomputed after a change (they must be tracked) in a performant manner...

[DanTup]

Yeah; I know my use is a bit weird (I don't know if there are other use cases for this) and I'm not sure whether decorations is the best way to handle it (in my case I am rendering decorations for this data, so it'd be convenient, but if making something more reusable it might make sense to keep separate).

For now, my mapping of edits seems to be working well so I don't think I'm blocked; but I might shout for ideas if I hit problems trying to maintain the state myself.

[alexdima]

I suggest we continue tracking in #54147, as #54147 has a more clear description and avoids the decoration pitfall by mentioning new explicit API for tracked ranges.