Neovim lsp functionality doesn't work until after file is edited.

[klcarlton]

Describe the bug
Lsp functionality (go to definition, find references, etc) doesn't work when a .fs file is first opened. Codelens for function definitions show "Unresolved lens ..."

Once I have edited the file and exited insert mode for the first time, all functionality starts working.

The lsp log file shows:
[ERROR][2021-11-14 14:11:16] .../vim/lsp/rpc.lua:462 "rpc" "dotnet" "stderr" "[14:11:16.356 WRN] [LSP] CodeLensResolve - Cached typecheck results not yet available for /home/kcarlton/dev/fsharp/FTest/src/App/Program.fs\n"

Environment

• OS: ubuntu 20.04 running in wsl2 on windows 11
• Neovim version: 0.5.1
• dotnet SDK version: 5.0.403
• .Net Framework version: 5.0.12

Additional context
Installed with vim-plug. Using nvim-lsp. No configuration set other than keybindings.

It looks like the InsertLeave autocmd is running condelens.refresh(). At this point lsp functionality starts working.
But manually running :lua vim.buf.codelense.refresh() before this doesn't do anything.

If I disable codelense:
let g:fsharp#lsp_codelens = 0
Then the lack of lsp functionality happens. But in this scenario running :lua vim.buf.codelense.refresh() restores functionality.

Plugin is working wonderfully otherwise!
I'm pretty new to neovim. Sorry if I've missed something dumb.

[OmanF]

I "see" klcarlton's issue and raise: when I start an F# file I get no LSP support at all, and worse, once I save a the file, the ionide LSP client automatically disengages.

See (the rather long, ~3 minutes) screencast.

2021-11-15_17h05_15.mp4

The lsp.log file (I've truncated it before running this test so it's quite empty):

Just to clarify what I mean by dos file type vs unix:

[cannorin]

@klcarlton it seems like it has something to do with the fact FSAC is kind of "slow" to launch, so that FSAC can't respond to the initial CodeLens request. I noticed when I use LanguageClient-neovim it correctly shows CodeLens from the beginning, so I'm suspecting Neovim's LSP implementation is weird (or maybe wrong).

@OmanF can you try dotnet restore/build, or if it still doesn't work, removing ./bin/, ./obj/, and .ionide (basically everything which would be in your .gitignore) if exists? In your case, it seems to me that FSAC is refusing to launch in the first place. It is known that FSAC sometimes refuses to work in a similar way, and removing those things often fixes the problem.

[cannorin]

@OmanF Also, if you restore/build your project in Windows anf try to edit it from WSL, FSAC tends not to work. Make sure to do dotnet restore in your WSL environment.

[OmanF]

I have tried your suggestions to no avail.
Interestingly, on two separate machines, on the machine I didn't take the screenshot on, while ionide still refuses to connect, the file type is the correct unix one and the LSP client doesn't disengage.
Both are Windows machines running WSL2, and in both cases I started the project from within WSL, and did both dotnet restore and dotnet build after first removing the bin/ and obj/ folders.

Any chance this has to do with me already switching to .Net 6? Because right now my SDK, on both machines in question, is 6.0.100!
Just tried starting a project, from within WSL2, with SDK 5.0.403... same results.

The interesting thing is that this happened right after the previous fix for an issue I posted.
If there's a way to use a previous version when doing PlugInstall I could verify this, A/B-testing style.

And, as always, thank you a lot for your effort!

[OmanF]

I think all issues are part of FSAC "childhood issues" with .Net 6... VSCode's Ionide's plugin is experiencing some issues as well (so much so, that they have a meta-issue to track .Net 6 specific issues).

Weird thing is that using a .Net 5 SDK doesn't remove those issues.
Maybe the fact that both SDKs are now installed on the same machine is causing issues... who knows?!

[cannorin]

@OmanF

A/B test for FSAC

Install an older version of FSAC as a .NET tool:

dotnet tool install --version 0.48.2 fsautocomplete -g

(if you have already installed it before, replace install with update)

Then use the following to force Ionide-vim to use the one from .NET tool:

let g:fsharp#fsautocomplete_command =
    \ [ 'dotnet',
    \   'fsautocomplete',
    \   '--background-service-enabled'
    \ ]

A/B test for Ionide-vim

I've created new tags issue43, issue43-2 for this.

Plug 'ionide/Ionide-vim', {
      \ 'do':  'make fsautocomplete',
      \ 'tag': 'issue43',
      \}

Plug 'ionide/Ionide-vim', {
      \ 'do':  'make fsautocomplete',
      \ 'tag': 'issue43-2',
      \}

Try both 🙂

My setup

$ dotnet --list-sdks
3.1.413 [/usr/share/dotnet/sdk]
5.0.401 [/usr/share/dotnet/sdk]
6.0.100 [/usr/share/dotnet/sdk]

$ dotnet fsautocomplete --version
FsAutoComplete 0.48.2 (git sha 0dd177dfdac3dfd74a3f55cbe65ecf942447ea62)

I'm using the latest Ionide-vim (no tag), and everything is working for me (besides the initial CodeLens etc). I suspect it is because the latest FSAC has some problem and you are using it. Also, I'm actually failing to run the latest FSAC in my WSL environment.

[cannorin]

@OmanF Also, from the next time, please create a new issue when you are not experiencing exactly the same problem as the original poster is. Your problem here is clearly different from what @klcarlton is experiencing.

I think ionide/FsAutoComplete#853 is the problem you are experiencing.

[cannorin]

See: #44

@klcarlton the problem you are experiencing is different from what is described in #44. I'll keep track of it in this issue. (try #44 if you are now affected by it too!)

[OmanF]

Will test once I'm off the work clock.
Sorry for misusing the current issue.

[klcarlton]

@cannorin
Thanks. I already had DOTNET_HOST_PATH set so I didn't experience those issues. Just the delayed fsac startup.
I noticed it only happens for .fs files and .fsx files work fine.

Looks like it's not an Ionide-Vim problem :)

[OmanF]

Upgrading fsautocomplete to 0.48.2 (not 0.49.1, this will fail the plugin!) and using the code to force the plugin to recognize the fsautocomplete (i.e. let g:fsharp#fsautocomplete_command =...) did the trick for me!

Neither of the A/B branches for testing the plugin worked!
Both gave the error as before about not being able to initialized a nil command (that the newest commit resolved).

Great, thank you very much!

[thyvini]

I'm having the same problem.

I've tried the version 0.48.2 for fsautocomplete and the plugin from tag issue43, and it shows the type signatures, but it is blinking (rapidly shows the 'Unresolved lens' and then turns into the type correct type). Autocomplete and errors/warnings seems to be working correctly.

[baronfel]

A fix for the language server not launching should have been pushed in 0.49.2, please let me know if it works out for you!

[klcarlton]

@LooserName404

I see the same rapid blinking. The lsp_client sends the "signature" request on every keystroke which seems to "restart" codelens.

My workaround is to disable updating the signature on every cursor move and not start codelens automatically:

let g:fsharp#show_signature_on_cursor_move = 0
let g:fsharp#lsp_codelens = 0

Then I mapped the codelens.refresh request and I only call it when I want.
nnoremap cl :lua vim.lsp.codelens.refresh()

A bit hacky but it works nicely.

[klcarlton]

@baronfel @cannorin

A screen recording of this issue, and the corresponding lsp.log. Not sure where I should actually be reporting this.

I open a file, navigate to an instance of the "whom" variable. I call go to definition and nothing happens. I edit the file. At this point signatures start working. Then I go to definition again. Now it works.

This is using the ioinde-vom project. But the behaviour is the same if instead I just use fsautocomplete directly with require'lspconfig'.fsautocomplete.setup{} which uses a local install of the latest fsautocomplete.

lsp.log