Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inline Hints controller and API proposal #113285

Merged
merged 40 commits into from
Jan 19, 2021

Conversation

Kingwl
Copy link
Contributor

@Kingwl Kingwl commented Dec 22, 2020

This PR will
fixes #113276
enables #16221

@Kingwl
Copy link
Contributor Author

Kingwl commented Dec 23, 2020

image

It's basically work on editor with new provider. But there are many things todo.
Signature arguments label is a temporary name. And I think we could confirm the name of the api.

@Kingwl
Copy link
Contributor Author

Kingwl commented Dec 24, 2020

wow

I think it's basically work on code side. We may going to improve

  • protocol
    • naming (feature name and protocol changes)
  • user experience
    • default styles
    • customized style
    • refresh schedule
    • may hide labels when user is editing some line.
  • performance
    • Should we add all decorations in a file? or only in the viewport
    • Do we need some cache?
  • code styles
    • Add missing comments
    • Lint
  • docs
    • I'm not sure what should i do
  • tests
    • I'm not sure too

@jrieken
Copy link
Member

jrieken commented Dec 24, 2020

/cc @CyrusNajmabadi

Thanks for starting this! This is quite an effort and you have come very far already 👏. I didn't do a full review yet (and likely won't before early January) but a few quick notes:

  • There exists a matching Roslyn API, they call this InlineHints which I think is a good name
  • Inline hints shouldn't be computed for the whole document but for ranges (the currently visible range). So the provide API must be like this provideInlineHint(document: TextDocument, range: Range, token: CancellationToken). The range should be the current view port. This will allow for better performance when dealing with large/huge files. However, this will make the editor contribution slightly more complex because you need to listen to view port changes, e.g ICodeEditor#onDidScrollChange
  • (optional) Inline hints can target a position or a range. A "position-hint" shows in-between the text (as you have implemented it), a range-hint overlays the text when a special mode is entered. Note that we can treat this as a separate work package and leave it out of this PR
  • I understand how the TypeScript implementation helps you drive this but at the end this should be spilt into two separate PRs - one for the API/feature and one for the TypeScript adoption
  • When adding new API don't put it in vscode.d.ts but in vscode.proposed.d.ts. Also use the checkProposedApiEnabled-function to guard proposed API from un-allowed usage (sample)
  • A few code nits. In addition to our coding guidelines each feature area owner has their own style preferences. For me that's: (1) prefix all private methods and fields with an underscore for better readability, (2) don't use the public-keyword because things are public by default, (3) don't extend from Disposable, use a DisposableStore-property instead. It's not urgent to make these changes but I would make them otherwise myself

@jrieken jrieken changed the title [WIP]: Support signature arguments label [WIP]: Inline Hints controller and API proposal Dec 24, 2020
@jrieken
Copy link
Member

jrieken commented Dec 24, 2020

more popular related issue: #16221

@jrieken
Copy link
Member

jrieken commented Dec 24, 2020

for reference the Roslyn/C# IInlineHintsService and friends: http://sourceroslyn.io/#Microsoft.CodeAnalysis.Features/InlineHints/IInlineHintsService.cs,79bf00b7826d13e4

@Kingwl
Copy link
Contributor Author

Kingwl commented Dec 24, 2020

Thanks for the review.

I'll do them soon.
Enjoy your vacation. Merry Christmas to you in advance.

@Kingwl
Copy link
Contributor Author

Kingwl commented Dec 24, 2020

Currently it's show the before decorations only.
Sould we support after decorations too?
If so, It will be more common.

Eg:
image

@jrieken
Copy link
Member

jrieken commented Dec 24, 2020

Currently it's show the before decorations only.

I think that's OK for now.

Enjoy your vacation. Merry Christmas to you in advance.

Thank you.

@CyrusNajmabadi
Copy link

LMK how i can be of assistance? I implemented this for VB and C# in Roslyn, and we'd obviously want the same computation to be portable over to whatever is created for VSCode/LSP.

@Kingwl
Copy link
Contributor Author

Kingwl commented Dec 24, 2020

@CyrusNajmabadi To take some review I guess.

/**
* The name of the parameter.
*/
name: string;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: in roslyn we support classified text in our 'hints', not just plain text.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also support the user hovering over these hints to get additional information (for example, what quick-info would show for teh entity in the hint).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CyrusNajmabadi
Copy link

CyrusNajmabadi commented Dec 24, 2020

Note: roslyn supports two modes for inline-hints (and allows hte languages to specify different behavior depending on the mode). The first mode is that the user can request the hints always be shown. THe second is that the hints are shown only when a certain keybinding is held down (in our case alt-f1).

Depending on which mode the user activates, we show different hints. For example, say the user has the code:

var v = Frob();

With the mode on to just always show hte hints, we'll display that as:

var v |string| = Frob();

image

In this manner, the inline-hint only augments the text, but never affects your ability to interact with anything. However, if the user holds down alt-f1 we will display this as:

|string| v = Frob();

image

Here, we actually overwrite a portion of teh user's text (the var) with the hint. This is not a problem and does not impact typing as it only is shown while the user is holding alt-f1.

@CyrusNajmabadi
Copy link

In terms of presentation, it looks like this in VS:

image

@Kingwl
Copy link
Contributor Author

Kingwl commented Dec 24, 2020

Note: roslyn supports two modes for inline-hints (and allows hte languages to specify different behavior depending on the mode).

I don't think that's a good idea to implement the overwrite mode now....
It's could be another iteration.

@jrieken
Copy link
Member

jrieken commented Jan 18, 2021

I have started in depth reviewing and also pushed a bunch of commits. Sorry, but I also removed some thing that got added in last days, namely:

  • Removal of the context menu for inline hints. That's not saying I don't like the idea of commands but this shouldn't be done via context keys and menu
  • Removal of the special hover tricks. Decorations already show hovers
  • Removal of some double decorations

I have also pushed a few cosmetic changes so that it is easier for me to work with these changes in the future. I will spend some more time on this branch and then I'll be ready to merge the current state.

@Kingwl
Copy link
Contributor Author

Kingwl commented Jan 18, 2021

Thank you very much. I'll read the changes too.

@Kingwl
Copy link
Contributor Author

Kingwl commented Jan 18, 2021

Cool. It's much simple and clear. Are there anything else can/need I do?

@Kingwl
Copy link
Contributor Author

Kingwl commented Jan 18, 2021

Removal of the special hover tricks. Decorations already show hovers.

I have tried to assign hover message into decoaration options. And there's no tooltip show.
And after debug. I think It's caused by zero length range - same as the colorPicker.
Another problem is before options does not have hoverMessage( Ok we could add one ).

PS. It's based my debug experience. So please let me know if there is any incorrect.

@jrieken
Copy link
Member

jrieken commented Jan 18, 2021

I have tried to assign hover message into decoaration options. And there's no tooltip show.

Yeah, that is correct. It works if you give a non empty range but my point is that it's an editor limitation and should be treated as such. E.g the editor should simply support such decorations with hover. I know it is tricky because ::before/after nodes don't really show up as event targets. So, some tricks are needed. I'll make sure to talk to the right folks here

@jrieken jrieken self-requested a review January 18, 2021 17:09
Copy link
Member

@jrieken jrieken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is still some follow-up work:

  • overlay mode
  • testing

I am planning on tackling that after merging

@jrieken jrieken added this to the January 2021 milestone Jan 18, 2021
@jrieken jrieken added the editor-contrib Editor collection of extras label Jan 18, 2021
@jrieken jrieken merged commit d29bb62 into microsoft:master Jan 19, 2021
@jrieken
Copy link
Member

jrieken commented Jan 19, 2021

Merged. This means we have proposed API for this and a first variant of the UI (inbetween rendering).

Thanks @Kingwl for this great contribution

@Kingwl Kingwl deleted the signaure_arguments_label branch January 19, 2021 08:24
@Kingwl
Copy link
Contributor Author

Kingwl commented Jan 19, 2021

I'm also happy to add more test cases or doc too!

@jrieken jrieken added the feature-request Request for new features or functionality label Jan 19, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Mar 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
editor-contrib Editor collection of extras feature-request Request for new features or functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support inline hints
5 participants