Inlay hints are truncated

[jk000]

• VS Code Version: 1.86.2
• OS Version: windows remote-ssh to linux

The LSP now truncates the array indices hint, making it hard to easily discern the total size of an array. This change occurred between versions 1.85.2 and 1.86.2. Tested below for clangd version 0.1.26

Before (1.85.2): The vector is clearly 18 elements.

After (1.86.2): A glance at the code is insufficient to easily determine the number of elements.

This is the same workspace on the same remote machine. The only difference is the version of vscode.

[jrieken]

We did that on purpose, there is now a limit of how many characters (overall per line) inlays can consume. We do this because long or many inlays push out the code and cause extra horizontal scrolling

[jk000]

Is it possible to make this configurable, either by a toggle or by allowing the adjustment of the number of characters?

For example this could be decided by the user in conjunction with the clang-format line length limit

[jk000]

For reference, when a formatter like clang-format applies a line length limit, this is how the inlay hints look (after/before): If this were a configurable option I would set it to some limit above the formatter's line length limit.

Also another point, in the context of having the word wrap option turned on, it seems the intention of this inlay character limit to reduce horizontal scrolling might not be applicable. In the following with word wrap enabled, I find the second case preferable:

[xidianzhangjun]

I also hope that the truncation of inlay hints could be configured. In most time of my work (c/c++ development), they help me a lot to review the code.

[xidianzhangjun]

I also hope that the truncation of inlay hints could be configured. In most time of my work (c/c++ development), they help me a lot to review the code.

@jrieken Thanks for your consideration.

[kojonek2]

It has to be configurable. Right now it's truncating inlines even when there is still space on the screen.

Simple on/off or configurable character limit would be enough probably

[Veykril]

Inlay hints are meant to show information that is hidden in the source. This feature goes completely against that. I get the idea behind adding this such that lines don't spill over, but why is this not configurable? Just like the debounce delay being a worse user experience to part of the user base, this does the same solely because neither have an exposed config. I see no reason why these kinds of changes have to be forced upon the user base when its clearly subjective whether this is an improvement or worsening of the feature.

[janriemer]

The truncation of inlay hints probably makes sense for TypeScript projects, but for many other languages I want to see the full inlay hints.

Please make this configurable.

See the following example in Rust - the right most inlay hint is truncated, but I want to see it, because it provides valuable information and the line wouldn't get significantly longer, when inlay hint is fully expanded:

Some interesting discussion also in #199610

• functionality of someones own language extension is severely limited by this
• future improvements for deciding when to truncate

[technic]

truncation must be per hint, not globally per line

[miszak]

With the hard limit when the lines are very short (but at the same time relatively rich in the inlay hint information), the inlay hint info is (unnecessarily) truncated, e.g.:

The limit has to be globally or, even better, per-language-extension configurable.

[PR0ras]

Now inlay hints is very hard to use it, because so many info are truncated in C/C++

[sandros94]

How am I supposed to debug this then? If I'm not even able to see the second param...

For context, this is how much space I have available. Clearly not on a mobile breakpoint.

[rafamerlin]

This is my first time contributing to VsCode but I believe I made it work properly, as I use vscode mainly for rust I rely quite a bit on the hints and having them truncated makes my life much harder, hopefully it will get merged soon.

@jrieken if you can give this one a look, I used the limit you added as the default value so there shouldn't be any impact to anyone who doesn't mind how it is right now

[bradphelan]

When coding in most languages specificity is most general to the left and most specific to the right. So if you have a namespace scoped calm

microsoft::filetools::FileHandle

the most specific and interesting part is FileHandle. If you were to truncate it makes more sense to truncate the less specific part. For example

...::FileHandle

is more immediately interesting than

micr...andle

For this reason I would suggest an option on strategy for how the ellipses is done. Either, Start, Middle, End for the truncation strategy.

[DEZREMNACUI]

"Due to the poor inlay hints in VS Code, I had to switch to Zed, as it provides complete inlay hints. Additionally, the Vue inlay hints in VS Code have a bug where, when scrolling up and down past the script section, the hints may toggle infinitely, causing the screen to flicker."

[bradphelan]

I'm currently staring at this And totally frustrated that the computer knows exactly what the type is and refuses to tell me. There is not even a tooltip over the inlay to expand what it knows is there.

[jrieken]

done with https://github.com/microsoft/vscode/pull/221276

[bradphelan]

Is it done that the inlay hints don't truncate in the middle or just that the length can be adjusted?

[rzhao271]

The PR adds a new setting editor.inlayHints.maximumLength that can be set to 0 to never truncate inlay hints.

@jrieken is this issue a candidate? If not, it should be on the September milestone.

[jrieken]

@jrieken is this issue a candidate? If not, it should be on the September milestone.

Sorry, wrong milestone

[GSmithApps]

Thanks so much everyone! I'm making an extension that aligns CSVs with inlay hints, and it didn't work until this fix. @rafamerlin I owe you a coffee if you have a venmo or anything

[GSmithApps]

Is there any way we could get this more granular? For example, per file type? Or maybe we could expose a new parameter to the inlay hint constructor that tells whether or not to truncate it? Because right now, I think the most fine-grained would be the workspace folder level. With the extension I'm working on, it might be nice to have certain truncation levels (or lack thereof) only applied to csv file types. And I could see applications with other file types too.

I think I can nearly implement what I need in the current setup, but I have to do hacky things like change workspace settings based on what file type the user has open. And I think even that won't work if the user has a rust file and a csv file open, because it will apply the same settings to both.

I might see if I can open up the code and implement something.

[HighCommander4]

Is there any way we could get this more granular? For example, per file type?

Note that you can already restrict settings to a file type, e.g.:

"[cpp]": {
  "editor.inlayHints.maximumLength": 0
}

[GSmithApps]

Thanks Nathan, that's awesome!! That definitely helps, and I just implemented it that way

After thinking some more, I still think it would be nice to allow the developers to pass this in as an argument. It seems like I have no option other than overwriting the user's persistent csv settings that apply outside of this extension, which doesn't feel right.

Maybe it could be an argument to vscode.InlayHintsProvider.provideInlayHints()

[jrieken]

To verify

• make sure the editor.inlayHints.maximumLength setting exists and works
• check that 0 means no truncation