"Code Lens" support for function types

[tylerhartwig]

After switching to Rider every day now for F#, this is the only thing I miss from VsCode + Ionide.

I think it's an awesome feature for F#, how hard would it be to get something similar in Rider? Does the IDEA platform support this kind of annotation?

[realvictorprm]

As I implemented code lens for VIsual Studio I also thought about implementing it for Rider and so talked with someone about this but was told that there isn't such an API available yet for an suitable implementation.

[vasily-kirichenko]

https://youtrack.jetbrains.com/issue/RIDER-2278

[tylerhartwig]

Are there updated plans for this now that CodeVision has been implemented in Rider? :)

[vasily-kirichenko]

Any updates?

[auduchinok]

@tylerhartwig @vasily-kirichenko It's planned for 2019.2.
To get updates you can vote for the issue about the feature.

[drhumlen]

I'm still holding my breath for this feature 😄

@auduchinok: Do you have an ETA?

[vasily-kirichenko]

@drhumlen

😝

[realvictorprm]

@vasily-kirichenko did you implement it?

[vasily-kirichenko]

No, it was our awesome @auduchinok

[realvictorprm]

It's a bummer, I would have loved to do it myself 😄 However I didn't know that the necessary stuff is already in IntelliJ.

[drhumlen]

@vasily-kirichenko : woa woa wi wa! very nice! 😄

Is there any way to try it out now? What do I have to do?

[auduchinok]

@vasily-kirichenko is being shy here. He's done a great job of prettifying the presentation and covering some cases missing in my prototype. 🙂

@drhumlen You'll need to build the plugin locally to test it. The most up to date version is in Vasily's PR. It's still missing some crucial parts (like properly registering the provider and adding tests) so me (or Vasily 🙂) will have to finish all the stuff before merging it in.

[drhumlen]

@auduchinok: I see. It's nice to see it's in progress. I would very much like to use it right away, even if it's not 100% and/or lacking in tests.

Is there any way for you to release it as an EAP/Beta even if it isn't perfect? And then finish up in upcoming PRs? Perhaps it could be a beta-toggle in the settings so people won't complain when it's not a 100%?

[vasily-kirichenko]

@drhumlen It's quite easy to build it yourself. See the dev guide. It's just a couple of gradle commands and a single .net solution build.

[drhumlen]

@vasily-kirichenko: I tried cloning your repo and opening it in Rider, but there's just too many IDE errors. Something about my local mono installation being too new (I have 5.x, but the project seems to require 4.x-series?). Not sure how to juggle multiple different versions of mono on my machine simultaneously (I'm not a .NET expert, as you can tell).

Is there any chance you could compile/zip it for me (and other future thread-visitors) so that I can install it in my current Rider? 😄

edit: attached the errors below in case it's relevant for you

edit2: and clicking the "Install mono" link brings me here:

[auduchinok]

The inferred types provider for Code Vision is now merged in and most likely will be available for testing in the next EAP build. Please file a separate issue if something goes wrong or should be done differently.
Thanks to @vasily-kirichenko for his help with this feature.

[drhumlen]

This feature turned out really great btw 😄 It's very helpful to watch the type inference as I write out my function; even more so for function that are polymorphic. Thanks for making this @auduchinok @vasily-kirichenko !

Question though: As of now, it only shows inferred type for top-level function/bindings & top-level inside module/class. It would be great to have the option to also see the type of local let-bindings – perhaps as an option? My functions and variables are mostly inside another function/binding, so an option to show inferred type for all bindings would be a game changer

[vasily-kirichenko]

@drhumlen After using the feature for a while, and because of https://youtrack.jetbrains.com/issue/RIDER-30413, I've switched it off :( It adds too much noise and effectively "reformats" code so that there are always empty lines.

So, I'm against showing even more lenses.

[drhumlen]

@vasily-kirichenko: Oh, I show the lens information inline (ie. on the same line as my code), so I don't have that problem fortunately. I also use a dim/gray color for the lens information so it's never distracting. I highly recommend trying that. Having type information ready without the need to hover (which often doesn't work for me fsor) is gold.

...But it's definitely a good idea to make it optional so people who only prefer to have it "top-level" can stick with that.

[tylerhartwig]

I too would like additional, local lens support for type inference. I agree it would make sense to have them off by default, it would be really nice to have them separately configurable as well, so that some lenses may be inline (for local functions, ect), and top level ones could be placed elsewhere if desired.

Personally, any scrolling effects do not bother me, and I love how configurable the IntelliJ platform is for each user.

[drhumlen]

@auduchinok: What do you think?

[auduchinok]

@auduchinok: What do you think?

I would personally prefer using inline type hints than the lenses for local symbols. In any case it'd need some more work, though. :)

Adding lenses and turning them off by default may make some sense but I think almost nobody will ever turn them on as not many people seem to tinker with such settings at all. I don't mind having this feature optionally but, given the amount of people I expect to ever enable it, I can't say it'd get a very high priority.

[drhumlen]

On by default then, with the option to turn it off? Also, people who dont tinker aren’t real developers if you ask me ;) should we really cater them first.?

Using lenses will make it even less intrusive than the inline rendering atm, so that sounds good.

@auduchinok But would it be possible to extend the current behaviour to local let-s now as a low-hanging fruit? Is it any harder than restricting it to top-level let-s?

[tylerhartwig]

I also think it being on by default wouldn't be a big deal, if the lens default location was inline rather than overhead.