Add ts inline hints

[Kingwl]

This PR fixes #113276

This PR should be merge after #113285

[Kingwl]

Friendly ping @mjbvz .

This PR is ready for review.

[mjbvz]

Thanks for all of your work on this feature!

I left a few comments for this PR. I'd also like the upstream TS pr to be merged in before we merge this

[Kingwl]

OKay. Thanks for the review. I'd like to update them after my work.

[Kingwl]

On the other hand, it would be nice if editors knew not to throw away prior inline hints if you've scrolled so the language service won't get asked about them again.

Sounds a good idea. We might need something to maintain the range. Are there any existed things like that?

[andrewbranch]

This is some generic feedback on the editor inline hints implementation, not this TS-specific support, but I wasn’t sure where else to share it. I found the experience of splitting up a long function call with parameter name hints extremely disorienting, because I wanted to put my cursor before the hint to move it down a line with the argument. But the cursor position only exists after the hint, so the impression you get as you make a refactor like this is that you’re actually inserting a newline between the label and the argument it’s labeling. And indeed, there is a moment of delay before the label disappears and reappears on the new line:

Kapture.2021-06-17.at.09.59.18.mp4

I obviously understand what’s happening and how I need to adjust for it—I’m exaggerating my struggle in this screen cap to demonstrate the nature of why it feels unintuitive—but it really is kind of jarring. It seems to me that you’d either want to duplicate the cursor position on either side of these labels, so it appears as if there are two cursor positions, even though they’re actually the same position in the source text, or you’d want an API that allows these labels to be “sticky” on either the start or end, which would control which side of the label you can place the cursor. Prefix labels like these would be sticky on their end side, such that you can’t separate the label from the argument that follows it. This would result not only in a more intuitive editing experience, but also fewer reflows of label position mid-edit like you see in every newline insertion here.

[Kingwl]

@andrewbranch

Sadly it's hard to allow cursor move to the left or right position. It's seems related to core cursor logic. You can see #113285.

For the user experience, I have an issue to improve the editor schedule.

[Kingwl]

TypeScript side is ready for the hints service API and it will be a part of v4.4 (microsoft/TypeScript#42089).
Now the ball backs to the VSCode side.

I have merged master and aligned with the latest changes.

[patroza]

@Kingwl very nice!
Would this also pave the way for better & more native support for inline-types?
https://marketplace.visualstudio.com/items?itemName=sokra.ts-inline-types

[Kingwl]

@Kingwl very nice!
Would this also pave the way for better & more native support for inline-types?
https://marketplace.visualstudio.com/items?itemName=sokra.ts-inline-types

Yep. You could wrote a typescript plugin to provide your own hints! (after this be done)

[niieani]

Awesome, thanks for this @Kingwl!

Suggestion: could the hints be optionally displayed in separate lines, above the actual code, so that they don't take up inline space? So that instead of taking up horizontal space, they'd take up vertical space. I currently use this feature in WebStorm, but sometimes it can be distracting when reading the code and doing selections. I think added lines would be less distracting. This also solves the mentioned above cursor position problem, because we're not actually placing anything inline with the code.

Of course this could be an option, but I think if we're doing implementation from scratch, it might be good to challenge the status quo assumptions.

I understand that then there would be the problem of the variable used as argument being shorter than the argument name - my solution to this would be to do an ellipsis abbreviation on that name and fit as much as possible, and have the full argument name show on hover.

[Kingwl]

could the hints be optionally displayed in separate lines, above the actual code,

I assume your means something like codelens? Well, I guess it could. But I have some concerns about that: It may take up too much vertical space. I'm not pretty sure that would be a good experience. @jrieken might have some suggestions.

[andrewbranch]

I think we should add descriptions for these too.

• None: Disable parameter name hints.
• Literals: Enable parameter name hints only for literal arguments.
• All: Enable parameter name hints for literal and non-literal arguments.

@DanielRosenwasser, can you think of a more approachable way to describe this?

[andrewbranch]

I guess if we can’t find a concise way to explain what literal expressions are or are not, these descriptions don’t add much.

[Kingwl]

Updated.

[mjbvz]

Some minor feedback but looks good overall

[mjbvz]

Also, we typically register two providers: one for TS files and one for JS files. This can make registering and unregistering them a bit simpler

[Kingwl]

Not pretty sure but I have some changes.

[mjbvz]

Thanks for all your amazing work here @Kingwl!

This change will be in the upcoming VS Code 1.59 insiders and is scheduled to be release in VS Code 1.59. It will still require upgrading to TS 4.4. We should bundle TS 4.4 with VS Code 1.60

[Akxe]

Hello everyone, this is a great addition. I would like to share my opinion on this :)

• One reason I like to split the multi-parameter functions into multiple lines is that I want all parameters to start at the same spot; adding an arbitrary long parameter name in front breaks this.
• Single line functions
  • are often simple enough for hints to be unnecessary
  • get too long if hints are inserted

I could see how many people will have a different point of view on this feature, but to me and potentially others from disabling it, I think like the ability to control when and where the hint gets paced...

Ability to enable/disable hints for:

• inferred variable type
• parameter name hint
  • display name hint only if it is different from the variable name passed to the parameter
• inferred function return type

class {
  method() {
    myMethod(
      callback, [callbackFunction]
      fileName, [path]
      options, [options]
    );
  }
}

I marked hints in [xxx] in the example above.

PS: I did not test it. I judge from the view @andrewbranch posted.

[pouyakary]

This is amazing and a huge wish coming true. Thanks a lot for doing this ♥️