Inlay hints schedule improve

[Kingwl]

Currently, the inlay hints will clean and shows again as scheduler's strategy.

It's might not friendly if you are editing some line who has many hints.

I have an idea:
Clean all hints where the cursor’s line when we are editing the code and append new hints by the scheduler.

I think It's might improve the experience about inlay hints.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• executeInlayHintProvider command description still mentions inline hints (#125545)

[gjsjohnmurray]

/gifPlease

[Kingwl]

[hediet]

I think inlay hints should disappear immediately if the surrounding text is deleted.
Afaik, currently, when text gets deleted, decorations inside of that text get collapsed but are not deleted.

[jrieken]

Yes, I agree that hints should disappear immediately when their "anchor" position is removed. Maybe it's not so easy to know what remove actually means in this case. Arguably this is an editor bug as I was expecting this to work?

[hediet]

Arguably this is an editor bug as I was expecting this to work?

I wouldn't call this a bug - decorations are never removed automatically.

Alex suggests (I asked him before his vacation):

yes, the inlay hints could listen to change events and remove them if they become collapsed

I also suggest to extend the inlay hints API so that a hint refers to a range. The hint itself then can either be after or before the range.
The range allows to better predict what should happen with the hint if the text changes.

With injected text, we now have two cursor stops around inlay hints - both refer to the same model position. Maybe the move behavior of inlay text should depend on the view position where the text change was caused from?

I suggest to think about how we can better predict synchronously how a text change affects inlay hints.

[jrieken]

I also suggest to extend the inlay hints API so that a hint refers to a range. The hint itself then can either be after or before the range. The range allows to better predict what should happen with the hint if the text changes.

This is how we started, mostly to optionally support overlay hints, and everyone was confused about ranges for inlay hints. Using a range with before/after screams "position" and I don't want to leak an implementation detail into the API. We would also still have the case of empty ranges... I'd rather create "fake ranges" from positions so that I can use the notion of collapsed ranges.