You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When can CodeLens be out of experimentation? #6964
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!
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
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.
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
Create an ASP.NET Core app, modify the following method:
[<HttpGet>]member_.Get()=letrng= System.Random()letx=12lety=13[|for index in0..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
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.
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.
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
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 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?
Activity
isaacabraham commentedon Jun 8, 2019
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 commentedon Jul 14, 2020
#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 commentedon Oct 18, 2020
I am looking into doing the following:
foo: intrather thanint)I've been playing with them and there are two quirks that I noticed:
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 commentedon Oct 18, 2020
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 commentedon Oct 18, 2020
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 commentedon Oct 18, 2020
Another quirk, definitely broken behavior:
Create an ASP.NET Core app, modify the following method:
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 commentedon Sep 16, 2021
@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 commentedon Sep 16, 2021
Yep, thanks, gonna look at it later in the month.
3 remaining items
psfinaki commentedon Sep 12, 2022
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 commentedon Sep 12, 2022
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 commentedon Sep 12, 2022
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 commentedon Sep 12, 2022
I see, got it. I thought Roslyn/VS did something which can be used out of the box already.
psfinaki commentedon Sep 12, 2022
@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 commentedon Sep 13, 2022
Aaaanyway I'll try to bring back to life the aforementioned branch and fix the aforementioned issue then. Wish me luck
abelbraaksma commentedon Sep 17, 2022
Related: #6066, some more repro screenshots there.