Language Server not starting without opening the folder

[jbeeko]

ScriptingBug.zip

Describe the bug
When a .fsx script file is opened directly using Open... the Language Server does not start reliably.

This report clarifies some prior reports. It seems that issues
#1371

Part of #1375
Part of #1378
And the behaviour commented on in #1357

Are due to the fact that the Language Server does not start reliably if a .fsx file edited by opening it directly rather than be opening a directory and then selecting the .fsx file in the File Explorer.

I think this is distinct from the race condition first identified in #1357.

How to Replicate

Primary Bug

1. Quit Ionide with no folder or file open.
2. Use Open... to open the file bug.fsx. Notice how syntax colouring is working but no Intellisense or Line Lens. This is because the Language Server has not been started.
3. Use Open.. to open TrickLSIntoStarting.fsx. The Language Sever may or may not start running. If not select all and comment out all code. Then uncomment all code. Wait a bit and notice how Language Server starts. Why this works I have no idea. See this video of the effect: https://youtu.be/9uvss4cWAAg
4. Now go back to bug.fsx. Typically the Language Sever will not be running for that file. But sometimes it is. If not running the commenting out trick does not seem to work. The OUTPUT will contain a lot of:

Error - 8:50:46 AM] Request textDocument/hover failed.
Message: Cached typecheck results not yet available
Code: -32603 

5. Now Save As... TrickLSIntoStarting.fsx. Notice the following in the output. Also notice the Lanuage Server is no longer running, and there is no Line Lens etc. It will not restart on it's own though the commenting out trick will start it.

[08:16:32.742 ERR] [LSP] PositionHandler - Getting file checker options for /Users/joergbeekmann/Desktop/ScriptingBug/1bug.fsx failed
[08:16:32.742 ERR] [LSP] PositionHandler - Getting file checker options for /Users/joergbeekmann/Desktop/ScriptingBug/1bug.fsx failed

Probably Related Bug
If you quit VSCode with no file or Directory open and then use Open... to open the Directory ScriptingBug Language Services lite up as files are selected in the VSCode File Explorer, i.e. things work as they should.

However if you quit VSCode with a script file opened by selecting it in the File Explorer and then quite and restart VSCode the file will be auto-reopened BUT no laguage services will be active for that auto-opened file. This does not change even if the editor is closed and reopened using the File Explorer. However other .fsx files opened will have language servcies.

What should happen

1. Directly opening a .fsx file should start the language server.
2. After a Save as the Language Sever should recover from not being able to find the file checker options.

Further observation/discussion/ideas
Even when the Laguage Server starts on a file no .ionide directory is created. This is the correct behavior otherwise these will clutter up the users file system.

Could these notifications Message: Cached typecheck results not yet available be used to try start the LS if not running?

Is there a reliable "starting to edit even VSCode generates that can be used to start the LS?

Why is syntax highlighting working but not the LS could this be used to start the LS

Issue #1378 reports errors thrown when creating a new un-saved file with F# mode selected. The behaviour differs based on if a file was opend or a directory was opened. In both cases the errors shown in that bug are reported to the output. But

1. directory opened and then a new file created - in this case hover help tips appear but line lens doesn ot
2. no directory opened and a new file created

Environment (please complete the following information):

• OS: OSX
• Ionide version: 4.11.1
• VSCode version: 1.45.1
• dotnet SDK version: 5.0 preview 4
• mono / .Net Framework version: not installed

[open-collective-bot[bot]]

Hey @jbeeko 👋,

Thank you for opening an issue. We will get back to you as
soon as we can. Also, check out our OpenCollective and consider
backing us.

https://opencollective.com/ionide

PS.: We offer backer support for all backers. Don't forget to add backer label when you start backing us 😄

[jbeeko]

@Krzysztof-Cieslak How should I handle the "related bugs referenced? Leave them or close them with a reference here?

[Krzysztof-Cieslak]

Are due to the fact that the Language Server does not start reliably if a .fsx file edited by opening it directly rather than be opening a directory and then selecting the .fsx file in the File Explorer.

Requiring to open Folder and the fact files need to belong to the opened folder (or subfolders) is by-design behaviour of Ionide/FSAC. I don't think we plan to change it.

[jbeeko]

I don't think we plan to change it.

@Krzysztof-Cieslak is this due to a technical constraint, because of the effort to make the change or, because the designers feel that is the way it should be for a UX perspective?

It does seem to almost work andI think there is value in being able to open an .fsx file anywhere and get editor support. For example downloading sample scripts in and being able to just open them rather than needing to put them in a directory and opening the directory.

I was poking around trying to find where FSAC is started. If this can be made to work would such a PR be declined?

All that said, if this decision will not be changed then perhaps there should be a warning of some sort when an isolated .fsx file is opened. The current "it kinda works some of the time" behaviour is quite confusing.

[Krzysztof-Cieslak]

No, it’s not almost working :-)

There are plenty of things in FsAutoComplete that currently assume that it runs in a folder that contains files. Things like path normalization, handling absolute paths vs relative paths, locations for creating caches (like .ionide folder), file watchers. All those things are parts of different layers of FSAC and ProjectSystem

Supporting running FSAC out-of-work-folder would require lot of work and lot of special code paths for just this scenario. I think it’s too “expensive” and too risky to do.

[jbeeko]

Ok I looked at references to workspace.rootPath and I see your point. But I think you underestimate the potential for confusion the current situation creates. There are a lot of paths on which the editor support will stop working and it is not clear why. As I said before if opening a .fsx file outside a workspace (aka directory) will not be supported that should be explicit.

I think you are also under estimating the value of this scenario. One premise of Ionide is that it is the simple low-friction quick way to get going with FSharp and not supporting script files outside a workspace goes against that. I think this will be an even bigger issue once the new #r directive hits. With .NET 5.0 there will be an expectation that one can just open a .fsx file put in some nuget refs and go. Think of being able to download a Waypoint literate .fsx script. Or using Ionide in an educational environment where, having students just work with a .fsx file is simpler than explaining projects or workspaces.

So should this issue just be closed or have I convinced you it is a valid feature request and should be tagged as such?

[jbeeko]

It seems some of this work may overlap with the work needed to address #1204

[Krzysztof-Cieslak]

Ok I looked at references to workspace.rootPath

It's not only this - In FASC, basically every Path.GetFullPath, file system abstraction, path normalization etc works under the assumption that the FSAC process is running in the root of the workspace.

[jbeeko]

Both Windows and MacOS have well defined ways to create temp directories. What about if there is no workspace.rootPath creating a temp directory and using that? I would guess such a change would be much less invasive.

[OkayX6]

Another easy UI (temporary?) workaround could be to trigger a pop-up asking if the user wants to open the file as part of its enclosing folder?

[Krzysztof-Cieslak]

@OkayX6 sounds like nice UX improvement.

[jbeeko]

It seems that the symbols cache is the only thing getting written into the .ionide folder. So when opening a "bare" .fsx file a thought I had was to automatically make the enclosing folder the workspace, without a prompt, and then open SQLite in memory. The db's when working with .fsx files alone are pretty small.

[kevingentile]

I found this coming from #1275. My encounter and workaround is a follows (macOS Catalina; ionide v4.17.0; vscode 1.51.1; dotnet 5.0.100):

1. Install .NET SDK
2. Create new F# Project and open in vscode
3. Install ionide extension through vscode
4. Reload vscode window

At this point the previously opened project did not have any of the ionide feature available to it.

5. Re-open the current project folder through vscode file explorer

This enabled the iodine features on open.

[Krzysztof-Cieslak]

5.1.0 enables initial support for "standalone" .fsx files opened without any folder. Bugs are expected