Change:
class EditorInlayHints extends BaseEditorOption<EditorOption.inlayHints, IEditorInlayHintsOptions, EditorInlayHintsOptions> { constructor() { <del> const defaults: EditorInlayHintsOptions = { enabled: 'on', fontSize: 0, fontFamily: '', displayStyle: 'compact' }; </del> <ins> const defaults: EditorInlayHintsOptions = { enabled: 'on', fontSize: 0, fontFamily: '', padding: false }; </ins> super( EditorOption.inlayHints, 'inlayHints', defaults, {

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.67.0 OS Version: Windows 11 21H2 .613 Steps to Reproduce: inlay hints with options like that the appearance of the inlay hints has changed For comparison: 1.66.2: ! 67.0: ! I haven't seen any mention of this in the changelog
Do you have a value set for ?
apparently changed the default from 90% of editor font size to 100%.
Yeah, that was done on purpose and with the goal to make inlay hints render more like source code. As already pointed out you can still change the size via the setting. This is "as designed" but leaving this issue open to await more feedback
Hi, so changing the fontSize does make the size similar to what what in the previous version, but the appearance of the hint box (the rounded corners) are not present anymore. I've checked in the settings and I don't see to see an option to toggle this on again. Smaller hints, but still a flat rectangle ! I don't think making the hints more like source code is a good idea, I use the inlay hints a lot for Rust and when using the Vim extension, if the hints are too similar to flat code you might try to navigate to it or through it by mistaking it for code which might be a side effect that's undesirable. You might wonder why your navigation keys don't bring you where you want when it's actually not text.

With this shape right now (without resizing the font size), it looks like highlighted text, not something that's just "floating" above your text to bring additional information.
See for me context on the padding. There was an effort to make inlay hint more compact, there was a setting but because many folks preferred compact we disabled the setting and went with compact only. We can bring back the setting but again awaiting more feedback
As a user of rust-analyzer also, I get the concerns of the author of that issue, I also liked the feeling of how the extension did the inlay hints before the update to the VSCode ones, but I think things like the padding should be configurable, I personally like the new look with the padding and the corners. Maybe a option to set the style with options like ?
As a user of clangd, I do NOT think it's a good idea to make inlay hints like source code, because C++ has no corresponding syntax. Anyway, if someone like the new look while the others like the old look, it's good to add options such as .
The inlay hints in Intellij are displayed with system UI fonts (such as Helvetica or sth) rather than code fonts, which makes sense for me. However, that's not what vscode does. It'll be so great to add this feature.
Since we're bikeshedding, I kinda' liked the padding, since now the edge of the background is too close to the text and looks ugly (cut off) IMO. It doesn't even have to be a lot of padding, maybe 1px would be enough. Look at this variant of the "Comment" button on GitHub to see how important the whitespace is: ! As for the font size, I prefer hints to be slightly smaller. I can set it, but in a way it would be nice to be able to use a percentage, since I sometimes change my editor font size. But this isn't that important. It also a bit weird that the commit that switched to the "compact" mode also increased the font size, making them less compact.
Emmm... There is
idk about that, thanks a lot haha.

Then the padding style will be the only difference
If that's possible, I too would like to be able to switch back to padding + rounded corners for inlay hints
I also prefer the old look with rounded corners and think an option to set the preferred style, such as that others have mentioned, would allow users the flexibility of choosing the style that best suits them.
This absolutely needs to be configurable on more axes than are available.
I think it's really a bad idea to make inlay hints looks just like source code. As inlay hints are 'hints' instead of actual 'code', it's quite important to make them distinguishable by default. Also, I really want the rounded corner style back. The rectangle one now looks kind of awful.
FWIW, I think the needs to be enabled no matter what the inlay style is ( or ). Because if we use different font sizes for code and inlay hints, not having that rule messes up the line alignment. Do you mind if a make a PR for this? I will bring back the option (maybe name it or )? Fix the alignment issue with different font sizes.
Sure - it should be only about uncommenting a few lines . I'll be OOF soon'ish and will wait till Tuesday for your PR. Thanks!
Maybe renaming the options is needed too. Today there is and - it should be less biased (no standard) and maybe 'likeCode' and 'likeWidget' ?
Next (tomorrows) insiders build will have this option:
I am getting conflicting results. With I get misaligned lines even when using the same font for both code and inlay hints: ! but, when I disable the css I get properly aligned text: ! ! This happens with or without padding being enabled. Do you have any ideas on what could be causing this? Or if this behavior is intended?