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.