When can CodeLens be out of experimentation?

[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.

[isaacabraham]

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.

[abelbraaksma]

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!

[cartermp]

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

[cartermp]

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.

[cartermp]

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

[cartermp]

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.

Another quirk that would need to get addressed: #11257

[cartermp]

@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.

[vzarytovskii]

@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.

[psfinaki]

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

[vzarytovskii]

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.

[cartermp]

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.

[vzarytovskii]

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.

[psfinaki]

@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?

[psfinaki]

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

[abelbraaksma]

Related: #6066, some more repro screenshots there.