Skip to content

When can CodeLens be out of experimentation? #6964

Closed

Description

@Happypig375

Is your feature request related to a problem? Please describe.
It's been a year. Is CodeLens going the path of Gmail which stayed in beta for years?

Describe the solution you'd like
Merge #5145, fix #4551, and ship CodeLens, then finally be on par with Ionide.

Describe alternatives you've considered
Keeping the status quo. Turn productivity features off by default. Make Ionide better at first glance.

Additional context
Please do #4087 asap as well.

Activity

  1. isaacabraham commented on Jun 8, 2019

    @isaacabraham
    Contributor

    I think @realvictorprm is going to try getting the caching issue solved by bringing master into his prs so that they're in a position to merge.

  2. abelbraaksma commented on Jul 14, 2020

    @abelbraaksma
    Contributor

    Merge #5145, fix #4551, and ship CodeLens, then finally be on par with Ionide.

    #5145 has meanwhile been merged. I'm not sure about #4551 if that's still an issue. Would be great though to get this stable for F# 5.0, it's a great feature!

  3. cartermp commented on Oct 18, 2020

    @cartermp
    Contributor

    I am looking into doing the following:

    • Turning the feature on by default for everyone in 16.9 preview
    • Looking into if the text buffer can be drawn when a document is parsed rather than after it is typechecked, so that the space is "allocated" before it fills in with data. This would help make the screen look a little less jittery when applying lenses for the first time
    • Improving the artificial delays placed in there to see what all can be improved so it feels snappier
    • Improving code quality to make it easier for people to come in and contribute improvements
    • Moving the settings to "Advanced" instead of its own node in the text editor settings
    • Seeing what all (if anything) can be done about adjusting the font and font size; they currently derive from Editor Tooltips rather than CodeLens in the VS Fonts and Colors settings
    • Removing LineLenses (they simply annotate the source too poorly)
    • Adjusting the printed signature to optionally specify the name (foo: int rather than int)
    • Looking into anything that can be improved for the colorization option

    I've been playing with them and there are two quirks that I noticed:

    • More tweaking in the artificial delays is necessary, the default is too slow
    • When doing inline rename sometimes the adornment gets weird before you scroll and it appears again

    I think more will be noticed if I just turn it on by default in the 16.9 previews and await feedback to indicate it's ready/not ready

  4. cartermp commented on Oct 18, 2020

    @cartermp
    Contributor

    Okay, additional quirk related to renaming. Various edits that move lots of code around will keep old adornments that screw up the editor. The service needs to invalidate more frequently.

  5. cartermp commented on Oct 18, 2020

    @cartermp
    Contributor

    Another quirk I noticed in a new .NET 5 web app is that the lenses will sometimes stagger on when they come in, even though the document is typechecked and a lens is already available elsewhere in the document. Not fundamentally broken but clearly needs some tweaking

  6. cartermp commented on Oct 18, 2020

    @cartermp
    Contributor

    Another quirk, definitely broken behavior:

    Create an ASP.NET Core app, modify the following method:

        [<HttpGet>]
        member _.Get() =
            let rng = System.Random()
    
            let x = 12
            let y = 13
    
            [|
                for index in 0..4 ->
                    { Date = DateTime.Now.AddDays(float index)
                      TemperatureC = rng.Next(-20,55)
                      Summary = summaries.[rng.Next(summaries.Length)] }
            |]

    Very, very slowly type out a new value binding let x = . At some point the textblock for the code lens will be empty, and any further typing will have it draw at the very top of the file.

    image

    Another quirk that would need to get addressed: #11257

  7. cartermp commented on Sep 16, 2021

    @cartermp
    Contributor

    @vzarytovskii if you're interested in figuring out the rendering quirk, my branch is here: main...cartermp:codelens-bringup

    It has diverged a bit mostly in resource files and a few API calls that had to get updated to account for FCS changes. But this is the state that isolates the rendering problem.

  8. vzarytovskii commented on Sep 16, 2021

    @vzarytovskii
    Member

    @vzarytovskii if you're interested in figuring out the rendering quirk, my branch is here: main...cartermp:codelens-bringup

    It has diverged a bit mostly in resource files and a few API calls that had to get updated to account for FCS changes. But this is the state that isolates the rendering problem.

    Yep, thanks, gonna look at it later in the month.

  9. self-assigned this
    on Sep 16, 2021
  10. 3 remaining items

  11. psfinaki commented on Sep 12, 2022

    @psfinaki
    Contributor

    So where are we with this?
    The bug noticed by @cartermp is still there, I've just created a separate issue for that and will take it.

    But in general this seems to be quite a useful thing and definitely worth having in on by default, do we have any blockers for doing that? @KathleenDollard

  12. vzarytovskii commented on Sep 12, 2022

    @vzarytovskii
    Member

    do we have any blockers for doing that?

    Well, the only blocker would be that the rendering is broken. Which needs fixing.

    I don't know what is used for rendering - is it built-in mechanism (the same C# use)? If not, we should probably make it use built-in mechanism, and do not reinvent our own.

  13. cartermp commented on Sep 12, 2022

    @cartermp
    Contributor

    Rendering is some custom WPF code. It's the most complicated part of it. My branch I have linked resolves all the other quirks with it.

  14. vzarytovskii commented on Sep 12, 2022

    @vzarytovskii
    Member

    Rendering is some custom WPF code. It's the most complicated part of it. My branch I have linked resolves all the other quirks with it.

    I see, got it. I thought Roslyn/VS did something which can be used out of the box already.

  15. psfinaki commented on Sep 12, 2022

    @psfinaki
    Contributor

    @cartermp so there were more quirks, right? If you think the branch is still worth reactivating, I will take it from there.
    Also Phillip, do you know who can be a good person to reach out to with this WPF stuff?

  16. psfinaki commented on Sep 13, 2022

    @psfinaki
    Contributor

    Aaaanyway I'll try to bring back to life the aforementioned branch and fix the aforementioned issue then. Wish me luck

  17. abelbraaksma commented on Sep 17, 2022

    @abelbraaksma
    Contributor

    Related: #6066, some more repro screenshots there.

  18. locked and limited conversation to collaborators on Oct 6, 2022
  19. converted this issue into a discussion #14031 on Oct 6, 2022
  20. Repository owner moved this from Not Planned to Done in F# Compiler and Toolingon Oct 6, 2022
  21. modified the milestones: Backlog, October-2022 on Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions