discussion: disable vscode inlay hints by default

[notpeter]

Hello all,

I am a novice Rust user. I recently began using vscode with the rust-analyzer extension and found the display of non code text (e.g. types, parameter names) inline by-default extremely confusing. I believe these are "inlay-hints".

I'd like to proposing that these should not be by-default enabled and so the following settings should default to:

    "rust-analyzer.inlayHints.typeHints.enable": false,
    "rust-analyzer.inlayHints.parameterHints.enable": false,
    "rust-analyzer.inlayHints.chainingHints.enable": false,

Although I'm sure more seasoned Rust developers will mentally skip over them, or already have "editor.inlayHints.enabled": "off" set globally, but I want specifically call-out that displaying non-code text inline is a really novice-hostile feature.

Here is a real-world recreation of me trying to manually type-out a line nearly identically to an existing line and managing to create a syntax error which the editor and extensions are no help.

Screen.Recording.2022-10-25.at.20.10.13.mov

I understand that this may seem trivial to other folks and now my global settings.json includes

"editor.inlayHints.enabled": "offUnlessPressed",

I'll never run into this again, but this is the first time I've encountered an vscode extension or any IDE for that matter which included non-text tokens inline in the in my editor, by default, so I wanted to call it as potentially a novice-hostile default.

External discussions:

• https://www.reddit.com/r/rust/comments/ulbbtn/inlay_hints_on_or_off/
• https://www.reddit.com/r/rust/comments/ujekgj/new_vs_code_167_feature_can_toggle_rustanalyzers/
• https://twitter.com/notpeter/status/1585057924082466816

[lnicola]

Our policy is to enable features by default, because it's very hard to discover them otherwise. You're not the first one to complain, but I'm pretty sure that a large majority of users like the hints and/or can disable then without much trouble.

[notpeter]

Our policy is to enable features by default, because it's very hard to discover them otherwise. You're not the first one to complain, but I'm pretty sure that a large majority of users like the hints and/or can disable then without much trouble.

Thanks @lnicola. Is this policy codified anywhere? Or is there previous discussions (Zulip?) you can link to where this was discussed?

My counter-argument is that it's even harder for a novice discover settings to disable the things that they don't even understand what "feature" is causing the confusion.

Additionally there appears that there was previously a global setting rust-analyzer.inlayHints.enable but now it's spread across half a dozen distinct settings. Perhaps the documentation for the individual settings should reference editor.inlayHints.enabled so users might find that single setting rather than having to hunt down half a dozen individual features to disable..

[jonas-schievink]

I don't think our stance will change here, but this may also be a discussion better had with the VS Code developers. After all editor.inlayHints.enabled is on by default, so their intent is clearly to have inlay hints show up by default. Maybe they're open to changing it to offUnlessPressed, or to change the default style to make it clearer that they aren't code?

[lnicola]

Is this policy codified anywhere? Or is there previous discussions (Zulip?) you can link to where this was discussed?

I think it was discussed in other issues, but not on Zulip. I filed #13496 to have it at dritten down, at least.

My counter-argument is that it's even harder for a novice discover settings to disable the things that they don't even understand what "feature" is causing the confusion.

It's easy to ask about something that annoys you. You can search the Web, post on Reddit, post in the URLO section, ping someone on the team on Twitter, file an issue and so on. You can't ask about something you don't know it exists.

Additionally there appears that there was previously a global setting #4372 but now it's spread across half a dozen distinct settings.

We could have one global toggle, but it might be somewhat confusing. I'm not opposed to it. But we can't point users to editor.inlayHints.enabled because that's a client (Code) setting. Inlay hints are part of the LSP, and we respond to them when the client asks. We don't have toggles to disable completion or diagnostics, although I'm sure that a lot of experienced developers hate auto-completion.

[flodiebold]

I think this would be something to mention on the landing page we were thinking about: #13351.

[notpeter]

this may also be a discussion better had with the VS Code developers. After all editor.inlayHints.enabled is on by default, so their intent is clearly to have inlay hints show up by default. Maybe they're open to changing it to offUnlessPressed, or to change the default style to make it clearer that they aren't code?

Thanks for suggesting I take this upstream. After some thinking, rather than disabling inlayHints by default (either in rust-analyzer or in vscode) I think a small tooltip might be enough to help new users identify on hover what they are seeing (an inlayHint) and how to disable it. See:

• Feature: identify Inlay Hints text (e.g. info in tooltip) microsoft/vscode#165009.

I found these two other feature inlayHints enhancement proposals too:

• Allow cusomizing the hotkey that shows/hides inlay hints microsoft/vscode#149019
• inlay hints toggle option microsoft/vscode#163201

Thanks everyone for your help on this. I think this is ok to close.

[jwalton]

As a rust n00b, and a long time VSCode user... wow this was confusing:

.app_data(ext: local_auth.clone())

"What's with that ext:? I didn't think rust supported keyword variables like Python? When I try to type a function like that I get compilation errors. What is going on!?" And then I tried to edit one of them, and realized I couldn't, and this must be rust-analyzer trying to be overly helpful.

Thanks @notpeter for "editor.inlayHints.enabled": "off".

[Veykril]

We should probably improve the hover message for parameter name inlay hints now that we can

[lnicola]

@jwalton you might want to give offUnlessPressed a try.

[rbuckland]

Unsure why, but the settings of

"rust-analyzer.inlayHints.typeHints.enable": false,

and

"rust-analyzer.inlayHints.enable": false

did not work.

I finally ended with alt+h toggling all inlay, regardless of language.

    {
        "key": "alt+h", // key to press to activate command
        "command": "settings.cycle", // `settings.cycle` is the command that's actually being run, from the extension `hoovercj.vscode-settings-cycler`
        "when": "editorTextFocus", // this keybinding is only active when (editor is in focus) and (the language is `rust`)
        "args": { // these are the arguments passed to `settings.cycle`
          "id": "toggle-language-inlay-hints", // must be unique
          "overrideWorkspaceSettings": true,
          "values": [ // Note: use the same settings in each values object
            {
              "editor.inlayHints.enabled": false
            },
            {
              "editor.inlayHints.enabled": true
            }
          ]
        }
      }

[a-non-a-mouse]

I'm pretty sure that a large majority of users like the hints and/or can disable then without much trouble

I've been a developer for close to 30 years, but am new to Rust. I've never seen inline text like this, and having to go hunt down reddit and github threads that tell me how to turn it off (or at least attach it to a key binding, as I do like the feature, just not while I'm trying to write code) is a bit ridiculous.

[lnicola]

@VoiceNPO it's a bit late now, but they're described in the manual. JetBrains IDEs have had them for a long time, clangd has them, and maybe others too.

We'd like a "welcome page" with explaining some of the more interesting features, but nobody is working on it.

[a-non-a-mouse]

Yeah, that was the point of my comment. 2 years later and new users are still searching for a solution on Google and being led here because it's such a non-standard thing to do and it's not even remotely obvious where to look to figure out what it's even called or how to turn it off.

[Veykril]

lnicola just showed you that this is in fact not a non-standard thing anymore though?

[jwalton]

I think at least part of the blame here lies with vscode, because it could make it more obvious what these things are when you hover over them or right click them or something. But part of the blame is definitely with this repo. There might be other tools using an annoying feature in vscode that no one knows how to turn off, but that doesn’t mean it’s right for this repo to use it by default.

[davidbarsky]

I think at least part of the blame here lies with vscode, because it could make it more obvious what these things are when you hover over them or right click them or something. But part of the blame is definitely with this repo. There might be other tools using an annoying feature in vscode that no one knows how to turn off, but that doesn’t mean it’s right for this repo to use it by default.

@jwalton Whether this is an annoying feature is debatable—I personally find them to be invaluable—but I've noticed that the small minority of users who dislike this feature often vehemently dislike this feature. Am I correct in thinking that a welcome page that gave you the language for what this feature is/gave you an option to disable them would be helpful for you?

[jwalton]

Well, someone went through the effort of developing it, so I’m sure someone likes it.  ;) But I’m in that second camp.Some sort of screen that pops up when you first install it?  That would definitely help.  I didn’t know what the feature was called, so figuring out how to turn it off was a chore.  Maybe even have toggles for the settings right on that screen, if that’s a thing that can be done in vscode plugins.On Jun 7, 2024, at 13:21, David Barsky ***@***.***> wrote: I think at least part of the blame here lies with vscode, because it could make it more obvious what these things are when you hover over them or right click them or something. But part of the blame is definitely with this repo. There might be other tools using an annoying feature in vscode that no one knows how to turn off, but that doesn’t mean it’s right for this repo to use it by default. @jwalton Whether this is an annoying feature is debatable—I personally find them to be invaluable—but I've noticed that the small minority of users who dislike this feature often vehemently dislike this feature. Am I correct in thinking that a welcome page that gave you the language for what this feature is/gave you an option to disable them would be helpful for you? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[BenGravell]

Just came here to voice my support for exposing the precise option to disable specific kinds of inlay hints with a tooltip. Coming from Python as a Rust noob, it is extremely confusing to see ghosted parameter names at function call sites (due to "rust-analyzer.inlayHints.parameterHints": true), as named arguments are not a feature in the Rust language. This is especially confusing as data type hints are double-clickable to actually add them in the code.

Why would

let x = 1.0;

become more correct/explicit with

let x: f64 = 1.0;

after double-clicking the type hint for f64, while

Array2::from_shape_vec((2, 2), vec_data).unwrap();

becomes incorrect non-compilable code with

Array2::from_shape_vec(shape: (2, 2), v: vec_data).unwrap();

per the suggestion of the inlay hints to add shape: and v:? At best I find these parameter inlay hints noisy clutter (yeah that's my personal opinion, others can reasonably disagree), at worst it leads to incorrect code (less debatable).

"editor.inlayHints.enabled": "off" does indeed make the offending inlay hints disappear, but it's way too heavy hammer to swing, as it disables otherwise useful inlay hints (basically all the other ones besides parameter hints) too.

[flodiebold]

@BenGravell I'm confused. Is "rust-analyzer.inlayHints.parameterHints": false not what you're looking for?

[BenGravell]

Is "rust-analyzer.inlayHints.parameterHints": false not what you're looking for?

Yes it is precisely the option I was looking for. My nit-picking requests are basically on the presentation:

1. Make this setting false by default instead of true to make it less of a novice-hostile footgun.
2. Expose the name of this option and how to change it in a tooltip upon hovering on a parameter hint.

[gar1t]

I think the premise that "all features should be enabled by default" is controversial and should be reconsidered. This is the opposite philosophy of almost all tools that I regularly use. It's not to say there's an obvious answer here, but the axiom that somehow every feature that you put into a tool needs to be presented to the user up-front is totally non-standard. There's enough angst in this thread to highlight this as a problem.

I'm well over it and thanks to the contributors to this thread it's no biggie, at all, but these ghosted symbols caused me great alarm :)

[djwashburn]

I haven't seen anyone mention how annoying it is having the alignment of your code and/or comments (which are supposed to be fixed-width!) messed up by the random insertion of arbitrary-width content in the middle of a line