Debounce refresh of inlay hints on buffer edits

[mrnugget]

I think this makes it less chaotic to edit text when the inlay hints are on.

It's for cases where you're editing to the right side of an inlay hint. Example:

for name in names.iter().map(|item| item.len()) {
    println!("{:?}", name);
}

We display a usize inlay hint right next to name.

But as soon as you remove that . in names.iter your cursor jumps around because the inlay hint has been removed.

With this change we now have a 700ms debounce before we update the inlay hints.

VS Code seems to have an even longer debounce, I think somewhere around ~1s.

Release Notes:

• Added a debounce to make it easier to edit text when inlay hints are enabled.

Before

https://github.com/zed-industries/zed/assets/1185253/3afbe548-dcfb-45a3-ab9f-cce14c04a148

After

https://github.com/zed-industries/zed/assets/1185253/7ea90e42-bca6-4f6c-995e-83324669ab43

[mikayla-maki]

Excited for this :D

[SomeoneToIgnore]

Can we have some kind of a setting for this? (enabled/disabled at least). My main issue with VSCode's impl is that they hardcode the debounce and never allow it to be changed.

[mrnugget]

Can we have some kind of a setting for this? (enabled/disabled at least). My main issue with VSCode's impl is that they hardcode the debounce and never allow it to be changed.

Yeah, I think we can do that. Will make the tests easier to fix too ;)

[mrnugget]

I've removed is_buffer_edited from the checks, to throttle all hint requests including scrolling and it works for me normally.

Ahh! I remember what was broken with that version: try toggling the inlay hints on and off. Whenever you turn them on, there's now a delay. I think that's bad UX because it feels slow.

[SomeoneToIgnore]

I'll add a patch for that soon-ish then, seems rather minor and we should not suddenly change the 0 debounce inlay hint updates before Wednesday anyway, due to the same slow concerns.