Support inlay hints in code chunks

[kv9898]

Use vscode.executeInlayHintProvider to retrieve hints for virtual docs and convert the ranges.

Here's a demo (with basedpyright+Positron)

inlayHints.mp4

[DavisVaughan]

I've done a decent amount of work looking at this and reworking the PR, but I'm honestly not sure if it is worth it because there are a number of restrictions. Basically the only time this seems to currently be useful right now is with Python when you are in VS Code.

It does seem like a nice feature but I'm not sure if it is worth the headache for us right now.

Does not work for Python in Positron by default

Jedi doesn't support inlay hints, so you don't get them by default in Positron. You have to also install basedpyright and I'm not sure if that is going to interact badly with our LSP or not.

Does not work for R

Since we don't have strong typing for R we won't be able to support this

Can't figure out why it doesn't work for TypeScript

I can't exactly figure out why, but a TypeScript code block {ts} doesn't seem to support inlay hints, while a TypeScript file does. If you want to test this, turn on these settings too

"typescript.inlayHints.parameterNames.enabled": "all",
"typescript.inlayHints.variableTypes.enabled": true,
"typescript.inlayHints.parameterTypes.enabled": true,

I'm also not sure what other languages that Quarto supports as "executable code blocks" would benefit from this.

Does not support the "resolve" aspect of inlay hints

This isn't a huge deal, but inlay hints are broken into two stages: "provide" and "resolve". Most LSP commands that are broken down in this way and are then called through an API command like vscode.executeInlayHintProvider will go ahead and call the "resolve" part for you, up to some N amount of items. But for whatever reason the inlay hint provider doesn't do this.

What this means in practice is that if your LSP "delays" the textEdits that are supposed to be provided for when a user double clicks on an inlay hint, then we never receive them. For example, basedpyright does not delay them, but pylance does, and you can see that in these two videos:

Screen.Recording.2025-05-20.at.12.22.40.PM.mov

Screen.Recording.2025-05-20.at.12.25.00.PM.mov

Accepting inlay hints can make arbitrary text edits

Maybe this is expected, but when you accept certain text edits it can also add import statements to the top of the file, like with Any here in Python. It ends up getting added to the first chunk. That's...probably right? But it's kind of odd in general.

Screen.Recording.2025-05-20.at.12.26.16.PM.mov

Have to avoid calling it on _quarto.yml and friends

Apparently the Quarto LSP tracks both .qmd files and some .yml files like _quarto.yml. I'm not sure why other providers like Completions don't complain about this, but if you naively call next() when we are given a yaml file that the user has open, then the user receives a toast notification of "Unhandled method inlayHint". Possibly some other provider is handling things like completions for yaml, and that's why we don't see this fall through message for that feature? I'm not sure.

I've worked around this for now by returning undefined when we encounter a quarto yaml file.

[juliasilge]

Thank you so much for this contribution, @kv9898! We so appreciate your willingness to dig into functionality across Positron, ark, and Quarto. 🙌

We chatted together and have decided that unfortunately we are not going to move forward with inlay hints for Quarto at the current time. We are not satisfied with where we have been able to get the experience to, starting with your work and then the time that @DavisVaughan has spent on it, especially relative to which kinds of users in what situations it will benefit.

Thank you again so much for your interest in these projects, and I'm sorry that we are not moving forward with this at the current time. Maybe we can spend more time in the future on how this LSP feature interacts in these complex Quarto situations.

[DavisVaughan]

Thanks again @kv9898!