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

More customization options for Pipeline Hints and LineLenses #1455

Closed
r-darwish opened this issue Dec 20, 2020 · 12 comments
Closed

More customization options for Pipeline Hints and LineLenses #1455

r-darwish opened this issue Dec 20, 2020 · 12 comments
Labels
enhancement Accepted suggestions that makes existing features better up for grabs Good first issues

Comments

@r-darwish
Copy link

Is your feature request related to a problem? Please describe.
Inlay hints appear as comments, which isn't the case with rust-analyzer. In addition, opening a new line after a variable causes the hint to be dropped to the next line, as seen in line 27

Describe the solution you'd like
I'm not a VS code extension developer so I can't tell which mechanism rust-analyzer uses, only quote from their manual:

Note: VS Code does not have native support for inlay hints yet and the hints are implemented using decorations. This approach has limitations, the caret movement and bracket highlighting near the edges of the hint may be weird

I think these issues might not be issues in Ionide since Ionide displays the hint at the end of each line, and using these decoration might appear better than using what seems like regular comments

Describe alternatives you've considered
Irrelevant

Additional context
image

@r-darwish r-darwish changed the title Better inlay hints Use decorations for inlay hints Dec 20, 2020
@cartermp
Copy link
Contributor

In this case it sounds like the request is it look like this:

foo : foo-type

as opposed to

foo // foo-type

yes?

@r-darwish
Copy link
Author

Yeah, but I also think rust-analyzer uses some other mechanism to display the text. The font isn't monospaced in rust-analyzer's hints, and the type hint won't go down the line if stand on line 11 col 14 and press enter

@baronfel
Copy link
Contributor

baronfel commented Dec 20, 2020

We use decorations for our hints, that's basically the only way to do things in VSCode.

It's worth noting that we have two primary kinds of signature decorations:

  • top-level signatures (like on a module-level function)
  • pipeline signatures (for an individual pipeline stage)

and the latter of these is getting a bit of a rework in #1453, so check that out and see if it addresses part of your request.

The other part of the request that I see (at least as far as the rust example shows) is to, for simple let value bindings (ie not functions) that are not already explicitly typed, render a text decoration that provides the type.

eg for

let magicNumber = 42

render that in the editor as

let magicNumber: int = 42

instead of

let magicNumber = 42 //int

(with the : int portion being a decoration).

Is that accurate?

@cartermp
Copy link
Contributor

Inline type hints as per here is certainly possible: dotnet/fsharp#10295

but I would also say that there's a desire to generalize this as an API point in vscode (some emails in my inbox indicate this) so I'm not sure how much it's worth really diving into a bespoke implementation especially when there's a lot of little quirks to work out in the presentation with something that isn't an overlay before a line or at the end of a line.

@baronfel
Copy link
Contributor

I'd forgotten about that MR @cartermp. What do you think the odds are of merging the FCS work there so that we could easily consume it in vscode as sort of a leading example of the feature? I suppose we could also lift the FCS portions to our FCSPatches file for trialing it...

@baronfel
Copy link
Contributor

and generally, we're fine with running custom implementations of things ahead of VSCode proper implementing a standarized form. Semantically aware syntax highlighting was the most recent example of us hacking it in before the feature standardized in the VSCode or LSP APIs.

@r-darwish
Copy link
Author

Making these inline would be nice, but I should say that my original intent was that Ionide will make its hints a bit more distinguished than the actual code, perhaps by using a non-monospace font and using : as the hint prefix instead of the comment characters.

@Krzysztof-Cieslak
Copy link
Member

You can set FSharp.pipelineHints.prefix and FSharp.lineLens.prefix to any perfix you want (with // being default).

We would accept a PR adding options to provide custom CSS for decoration type for both cases. It would require adding appropriate config entries and using them in those 2 places:

  1. https://github.com/ionide/ionide-vscode-fsharp/blob/master/src/Components/PipelineHints.fs#L96-L98
  2. https://github.com/ionide/ionide-vscode-fsharp/blob/master/src/Components/LineLens.fs#L117-L119

Relevant VSCode API documentation: https://code.visualstudio.com/api/references/vscode-api#ThemableDecorationAttachmentRenderOptions

@Krzysztof-Cieslak Krzysztof-Cieslak added enhancement Accepted suggestions that makes existing features better up for grabs Good first issues labels Dec 20, 2020
@Krzysztof-Cieslak Krzysztof-Cieslak changed the title Use decorations for inlay hints More customization options for Pipeline Hints and LineLenses Dec 20, 2020
@Krzysztof-Cieslak
Copy link
Member

Inline hints (as in dotnet/fsharp#10295) are something we plan to do, but it's out of the scope of the changes discussed here.

@voronoipotato
Copy link
Contributor

voronoipotato commented Dec 29, 2020

Rust-analyzer uses the stuff @Krzysztof-Cieslak was talking about

    const fg = new vscode.ThemeColor(`rust_analyzer.inlayHints.foreground.${hintKind}Hints`);
    const bg = new vscode.ThemeColor(`rust_analyzer.inlayHints.background.${hintKind}Hints`);
    return {
        decorationType: vscode.window.createTextEditorDecorationType({
            [pos]: {
                color: fg,
                backgroundColor: bg,
                fontStyle: "normal",
                fontWeight: "normal",
                textDecoration: ";font-size:smaller",
            },
        }),

when applied to ionide this yields a theme kinda like

image

I'm using pragmatapro-mono here but you'll notice the comment appears to not be mono. It is mono, it just is a bit smaller which creates the illusion of "non-mono".

When you were thinking about exposing custom css, am I right in thinking you were considering the "textDecoration" attribute? Or did you mean opening up more individual attributes?

I do think as a default it might be nice to have it be italic, normal, and smaller. Italics make it more like an actual comment and less in your face. Smaller helps it not look like real code.

@texastoland
Copy link

texastoland commented Sep 23, 2021

Moved from https://twitter.com/k_cieslak/status/1439265620504231936?s=20.

Parameter name hints are now supported with TypeScript 4.4

There's new official inlay hints (microsoft/vscode#113285) rendering like in VS, JS/TS support (microsoft/vscode#16221 (comment)), and proposed (but unstable) API (https://github.com/microsoft/vscode/blob/a1e69b746f92f3e1f8ab1c586567f2b848f77f87/src/vs/vscode.proposed.d.ts#L2153-L2232) to eventually replace line decorations.

@Krzysztof-Cieslak Would you prefer this as a separate issue?

@Krzysztof-Cieslak
Copy link
Member

We know have inlay hints support, so with them, code lenses, line lenses and pipeline hints there should be enough different ways to customize the experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Accepted suggestions that makes existing features better up for grabs Good first issues
Projects
None yet
Development

No branches or pull requests

6 participants