Fsharp: [ discussion ] Intellisense in Visual Sutdio

[HQDragon]

I spent a good time with f# coding,there is one thing annoying me that intellisense list won't show after a word's first character input ,i need to press CTRL+J to call the intellisense list for every new line's first word.
I see lonide-Fsharp extention can do that in vscode,is this feature on RoadMap?

[vasily-kirichenko]

@Huqin-China see https://github.com/Microsoft/visualfsharp/pull/1842

[HQDragon]

@vasily-kirichenko Aha,perfermance issue in large files,maybe provide this feature in small files first,close it in large files default ┏(＾0＾)┛.

[vasily-kirichenko]

We've fixed many perf issues, so intellisense should not block at all and pops up in not more than 1 second. So we can try to resurrect that PR, but the logic that determines _when_ it should be triggered is too simple and intellisense pops up too aggressively. Roslyn has rather complicated logic, but it cannot be ported as is because languages are different. Also it's critical to add user settings for this, similar to what C# has:

(I think a single one is of particular interest for us here - "show completion list after a character is typed")

So the plan is:

• add "Option -> Settings -> Text Editor -> F# -> Intellisense" settings dialog
• add "Show completion list after a character is typed" setting to it
• reactivate https://github.com/Microsoft/visualfsharp/pull/1842

Volunteers are very welcome :)

[HQDragon]

@vasily-kirichenko ,i tried to download , view,learn source code,but i found those works are too difficult for me (dummy),and i can't fix the building errors(branch rtm/master).
I will focus on this project and hope i can help some day in the future.

[smoothdeveloper]

@Huqin-China, if you encounter error messages that you can't find in a search among issues here (closed or opened), don't hesitate to post it, someone might be able to help or at least confirm being facing the same.

Thanks for your efforts and contribution.

[cartermp]

@Huqin-China The first steps would be:

1. Make sure that the .NET Desktop Development and Visual Studio Extension Development workloads are installed.
2. build vs from the VS 2017 command prompt run as administrator
3. msbuild Visual FSharp.sln from that command prompt (optional, I just prefer this)
4. Open VisualFSharp.sln
5. Set VisualFSharpOpenSource as the Startup project
6. f5 ---> will launch a debug hive of Visual Studio

If you're blocked on the above, then please log a bug describing your steps. We definitely want to fix that experience 🙂.

After that, it's just about picking a specific area that's interesting to you, learning the code (preferably while stepping through it in a debug session), and hopefully making a positive change.

[cartermp]

@vasily-kirichenko Regarding the logic about when F# should trigger IntelliSense, is that something you'd like to help spec out? I'm more than happy to start the process with a speclet, and I'd love to get feedback on that.

[majocha]

@vasily-kirichenko

So the plan is:

• add "Option -> Settings -> Text Editor -> F# -> Intellisense" settings dialog

It wouldn't be that much work if we had access to Roslyn's AbstractOptionPage etc.
For now the amount of effort that will likely be thrown away and replaced anyway is disheartening.

[Pilchie]

@vasily-kirichenko F# does have that access: https://github.com/dotnet/roslyn/blob/6181abfdf59da26da27f0dbedae2978df2f83768/src/VisualStudio/Core/Impl/ServicesVisualStudioImpl.csproj#L69

[vasily-kirichenko]

We have all our property pages in a separate (VB) project https://github.com/Microsoft/visualfsharp/tree/master/vsintegration/src/FSharp.ProjectSystem.PropertyPages. It's not listed as internals visible to in Roslyn.

@dsyme @KevinRansom is there a particular reason we have pages in that separate VB project? Should we add new stuff right into FSharp.Editor or into there?

[Pilchie]

Those are the project properties, not the Tools\Options pages. (Or, I don't know if a reason why Tools Options pages would need to be there).

[majocha]

It looks like Microsoft.VisualStudio.LanguageServices.Implementation.dll containing the AbstractOptionPage and AbstractOptionPageControl classes is not referenced anywhere in VisualFSharp solution.

[vasily-kirichenko]

@majocha It would be awesome if you take care of bringing the option pages to FSharp.Editor, see http://source.roslyn.io/#Microsoft.VisualStudio.LanguageServices.Implementation/Options/AbstractOptionPage.cs,1a13a0572f527b40,references

[HQDragon]

2425 compile issue

[vasily-kirichenko]

@Pilchie I cannot find the NuGet package that contains, say, AbstractOptionPage.

[majocha]

@vasily-kirichenko Yep, that's the showstopper at the moment.

[vasily-kirichenko]

@majocha I found one here c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\ManagedLanguages\VBCSharp\LanguageServices\ I think you can reference it directly for now to make progress.

[vasily-kirichenko]

@majocha An example of getting options http://source.roslyn.io/#Microsoft.CodeAnalysis.CSharp.Features/Completion/CSharpCompletionService.cs,74 (I _think_ that's what we need)

[majocha]

@vasily-kirichenko Awesome! I'll try to put together at least the visual part of the Intellisense page.
Taking a dependency on FsXaml would not be OK, I guess?

[vasily-kirichenko]

@majocha yes, please do not add FsXaml dependency, we have issues with it in VFPT (you cannot use a project that depends on a different version of FsXaml that the one used by VFPT, because it's already loaded into devenv.exe domain).
I think copy pasting this page http://source.roslyn.io/#Microsoft.VisualStudio.LanguageServices.CSharp/Options/IntelliSenseOptionPageControl.xaml.cs would be a good start.

[majocha]

@vasily-kirichenko I've ran into a problem.
All the needed Roslyn assemblies have <InternalsVisibleToFSharp Include="FSharp.Editor" />
That means that simply adding another C# project with copy-pasted IntelliSenseOptionPageControl won't work because it depends on Roslyn internals in codebehind.

Putting this functionality into FSharp.Editor would mean writing the UI in F# by hand? I'll try to investigate this option but maybe I'm missing something obvious.

[vasily-kirichenko]

@majocha Yes, we should try to add the UI manually into FSharp.Editor. Or we could add a new C# project just for these new options, but it'd require adding it into Roslyn's internals visible to list, which would take time and I don't think it would go even to Update 1.

What is the main problem with adding the UI to FSharp.Editor? Doesn't it just work if you copy paste *.cs => *.fs and *cs..xaml => *.fs.xaml files, then port C# code to F#? We don't need a lot of options at the moment, two or three actually.

[smoothdeveloper]

Can the FsXaml issue be solved with having our own FsXaml in a different namespace?

Doing the conversion from .xaml.cs won't make the code maintenable anytime we need a change.

[majocha]

@vasily-kirichenko there are no partial classes in F# and WPF implements "codebehind" with it. There is no simple conversion, but it is doable.

[vasily-kirichenko]

Then I think we should

• add a new signed C# project, like FSharp.VisualStudio.UI
• ask Roslyn team to add it to https://github.com/dotnet/roslyn/blob/6181abfdf59da26da27f0dbedae2978df2f83768/src/VisualStudio/Core/Impl/ServicesVisualStudioImpl.csproj#L69
• ask Roslyn team to publish Microsoft.VisualStudio.LanguageServices.Implementation as a NuGet package

@Pilchie is it possible?

[majocha]

I tried wiring up a simple Roslyn based OptionPage with the FSharpPackage.
Another problem surfaced.
The package depends on Shell.14.0 and registration with ProvideLanguageEditorOptionPage fails because the page is derived from Shell.15.0 DialogPage.
Looks like we can either update everything to 15.0 or lag behind and write our own Options infrastructure from scratch.

[vasily-kirichenko]

I think we can switch to Microsoft.VisualStudio.XXX 15. See project.json and FSharpSource.Settings.target. But be prepared that nothing will work, especially the tests.

[majocha]

In fact I tried. Most of the things work with some adjustments. Only ProjectSystem.Base breaks down with some missing methods. I understand it is to be replaced in full by CPS but looks like we're blocked till then.

[ReedCopsey]

Regarding FsXaml - I would second @vasily-kirichenko 's suggestion of avoiding taking a dependency on this in the library. The problems encountered in VFPT really highlight why it's a bad idea to take a dependency on a type provider on something that's going to run in the VS process.

A separate csproj with nothing but xaml (and xaml.cs) files would likely make the most sense. If you avoid code behind, there's really no disadvantage (other than an extra small assembly), and there are multiple advantages, most notably getting proper baml compilation. Given that this would be in the box in the main F# project, the boost in speed there is likely worth the pain of keeping it in C#.

If people really want to have the UI defined in F# instead of C#, I'd be willing to strip out enough of FsXaml to have an "in the box" minimum subset of required functionality to load xaml and get elements by name, but I don't think it'd be worth it, as the end result won't be as good as a small C# project for the xaml assets. (Note that I'd probably still not make this a type provider - but a minimal library to load this information would not be very difficult.)

[majocha]

The XAML in question is so simplistic, basically a stackpanel of some checkboxes, that it can be pieced together in a few lines of code, avoiding a c# project. Styling and clever binding to the datastore is taken care of in the base class - that's what would be more worth reusing than XAML itself.

[cartermp]

cc @KevinRansom regarding this:

In fact I tried. Most of the things work with some adjustments. Only ProjectSystem.Base breaks down with some missing methods. I understand it is to be replaced in full by CPS but looks like we're blocked till then.

[HQDragon]

i think we should make f# a great core lib tools first.Ms recommand users to write core ，math,datasience lib using f#.
let's defeat Python and IronPython first.

[dsyme]

Closing old discussion