make inlay hints typing debounce max delay configurable

[jhgg]

recently, rust-analyzer switched to using vs code's inlay hints provider. however, due to:

vscode/src/vs/editor/contrib/inlayHints/browser/inlayHintsController.ts

Line 214 in 778b74a

const delay = Math.max(scheduler.delay, 1250);

there is a delay for inlay hints when typing.

However, I think that this actually makes the experience feel much worse if your language server is able to compute inlay hints quite quickly, and indeed users of the extension have noted this fact as well!

I have only noticed that after I took the screenshot, I also couldn't reproduce whatever glitch that was. Maybe it's worth noting though, that at least in my case I have noticed that the inlay hints take longer now to render in my VsCode for whatever reason.

rust-lang/rust-analyzer#11733 (comment)

This feature requests proposes to make the hard-coded 1250 be configurable via user settings.

[lnicola]

So the reasoning here is to make them bounce less while editing the code. But if you make a change then move the caret, the hint for the original line still gets delayed.

Also, should that say Math.min? No, it seems intentional.

[ejpcmac]

Why would you even want a delay at all for type hints for instance? It’s annoying to have the impression the editor is not responsive like it used to be.

[lnicola]

@ejpcmac #133730 (comment)

[ejpcmac]

@ejpcmac #133730 (comment)

I don’t feel this is bad, even, this gives the feeling that the editor is really responsive. This is approximately what we had in rust-analyzer before they switched to the native inlay implementation, and I quite liked it. You don’t have to wait to see your changes. It seems not to be the taste of everyone though, so maybe we should need an option for this. However, what would be the default? Do the majority of users prefer reactivity or seeing the hints with a delay? How would the minority even be aware of such parameter to speed-up or slow-down their editor?

[lnicola]

I don't know. It looks a bit bad in that recording, but I used rust-analyzer before and the inlay hints never bothered me. I think you get used to it very quickly. Just so it's clear, I'm not arguing in favour of delaying updates like this, I just linked to the original issue what prompted it.

before they switched

Yeah, umm... 😅.

[ejpcmac]

before they switched

Yeah, umm... sweat_smile.

Oh, you’re a rust-analyzer contributor :) I’m not, hence the “they”. Hope it was not understood as a critique: it’s not. It’s a good thing to use the standard APIs, it just has currently some side effects in term of UX.

[hammypants]

This delay is ridiculously long. Please make it configurable. It feels like I'm coding in a swamp.

[cutsoy]

I'm working on a LSP that's not rust-analyzer and I also notice the delay. In my case, the hints are very fast to compute (less than 3ms) and the hints are always shown at the end of a line. E.g.:

const example = true        # Bool

Therefore, it wouldn't cause any editor unresponsiveness nor the bouncing layout that's mentioned earlier.

On the other hand, the current approach (waiting 1250ms) does cause a jittery layout when inserting a newline. In my example above, the inlay hint floats onto the wrong line while typing for 1250ms:

const example = true        
const newline = fal# Bool

In my opinion, this behavior is much less user friendly than updating the inlay hints in real time.

As a temporary work around, I tried sending a "workspace/inlayHint/refresh" request but that is either a no-op or suffers the same debounce as mentioned before.

Pragmatically, I see three solutions:

1. Remove the debounce delay all-together (and leave it up to the language server to introduce a delay if deemed necessary).
2. Make it possible for extensions to customize their own debounce delay.
3. Skip the debounce delay when the LSP sends an inlay hint refresh request.