swift-server
Add setting to turn inlay hints (inferred variable types) on or off
Is your feature request related to a problem? Please describe.
Currently the default behaviour of the extension is to turn on inlay hints. This adds inferred types with grey text, and the user can double click on the text to insert it into the code. For example the inlay hint for the Package variable type:
While many users like this feature, some may not appreciate it as much and feel like it affects the readability of the code. Additionally, they may not know where this text is coming from if they are new and what they should do to turn it on/off.
Describe the solution you'd like We should add a setting to turn inlay hints on and off. For now we can turn it off by default and when we add a walkthrough mode we should give the user the option to turn inlay hints on or off by default for swift projects. As well, we can update the documentation to tell users how to turn this feature on/off.
Describe alternatives you've considered It is possible to turn off inlay hints on or off for swift with the following setting in the settings.json file:
"[swift]": {
"editor.inlayHints.enabled": "off"
},
But users may not know that the inferred types are coming from "inlay hints".
Additional context We can possibly add a setting that will modify the settings.json to set the right editor.inlayHints.enabled values.
There is already a setting, it just isn't in the Swift settings. Search the settings for inlay hints.
Thank you! Yes, can definitely turn off inlay hints through the global settings as well (which would set "editor.inlayHints.enabled": "off" globally or for settings.json if done for the workspace I believe) but was thinking the Swift specific setting would be good when the extension is run for the first time and there is some sort of a walkthrough mode to help users configure preferences. New users may not know the setting name to search for and they could be new to VS Code in general as well.
Possibly inlay hints should have been called "variable type hints" or "variable type suggestions" or something to make it easier to find. Also instead of just "Double-click to insert" on hover perhaps it could say "Double-click to insert inlay hint" or show a link to the setting to hide it, but I'm not sure if that text can be overwritten.
I think the way F# shows type hints is one of the best ways of doing this, it puts them in virtual comments on the right side of the *code
Is something like this particularly easy to implement as an alternative mode of exhibition?
I think the way F# shows type hints is one of the best ways of doing this, it puts them in virtual comments on the right side of the *code
Is something like this particularly easy to implement as an alternative mode of exhibition?
Interesting, thanks for sharing this @JoaoVictorVP. Had not seen this style before. Certainly possible, but I think this will need quite a bit of additional work on the SourceKit LSP side to support this. Also I think the logic will need to handle cases where multiple types would need to be displayed and such (for a function call for example), which may be a little tricky. Currently VS Code just displays any hints coming from SourceKit LSP if the setting is turned on in VS Code.
Also, I'm currently wondering if we can just tackle this issue with #1572 where we talk about how to turn off inlay hints via default VS Code settings instead of adding additional extension specific settings that override default behaviour.
I think the way F# shows type hints is one of the best ways of doing this, it puts them in virtual comments on the right side of the *code
Is something like this particularly easy to implement as an alternative mode of exhibition?
Interesting, thanks for sharing this @JoaoVictorVP. Had not seen this style before. Certainly possible, but I think this will need quite a bit of additional work on the SourceKit LSP side to support this. Also I think the logic will need to handle cases where multiple types would need to be displayed and such (for a function call for example), which may be a little tricky. Currently VS Code just displays any hints coming from SourceKit LSP if the setting is turned on in VS Code.
Oh, I like the style very much, and F# is a very sweet and ergonomic language to work with in general. But I'm curious, why it would require additional work on the sourcekit lsp? I never worked with it before, but is not this just a matter of requesting type info from the LSP and displaying it in a specific manner?
For a function call, I think the way F# does this is by simply not showing by default, usually you would not need those either way (most languages I think don't show this at all), and F# is a very permissible language that infers even function params ->
It is also very configurable. This line lens shows the type on top of the variable as well, in the current settings it only shows usage, and in this case I configured the prefix to be // type: instead of just // , and it could be anything else
It also has a mode where it displays the names in front of the params and things like that (the default vscode setting), but what I like about this style, apart from the lesser amount of visual clutter, is that it does not change the code layout, so you can continue typing without it being constantly recalculated and changing the line
(with the default inlay hints; you can enable both at the same time, or disable either) ->
Also, I'm currently wondering if we can just tackle this issue with #1572 where we talk about how to turn off inlay hints via default VS Code settings instead of adding additional extension specific settings that override default behaviour.
I think this is an interesting approach, vscode already provides some default niceties for this like "onUnlessPressed" or "offUnlessPressed", so it could be more familiar to users
@rbenegal
Yup, just made an extension for it
multiple types ->
It's not as well integrated as natively, and currently it flickers a bit, but it works fine as long as the extension provides the inlay hints
