akinsho / flutter-tools.nvim

Tools to help create flutter apps in neovim using the native lsp

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug]: Fails with "Unable to edit document because the file was not previously opened: myfile.dart"

moonlitknight opened this issue · comments

Since upgrading from nvim 0.8, AstroVim 2 to nvim 0.9 AstroVim3, I get the above error after saving a .dart file with errors

<-- Please ensure that you have read the README.md -->
Yep
<-- Also report bugs using a minimal init.vim or init.lua rather than your full configuration -->
I'm using the default AstroVim3 configs with the default flutter-tools config
<-- Do Not Delete this template or will close the issue as it helps me debug reports -->
A clear and concise description of what the bug is.

The last few lines of the lsp log are

[DEBUG][2023-03-15 02:37:39] .../vim/lsp/rpc.lua:387    "rpc.receive"   {  jsonrpc = "2.0",  method = "$/progress",  params = {    token = "ANALYZING",    value = {      kind = "end"    }  }}
[DEBUG][2023-03-15 02:37:52] .../vim/lsp/rpc.lua:284    "rpc.send"      {  jsonrpc = "2.0",  method = "textDocument/didChange",  params = {    contentChanges = { {        range = {          ["end"] = {            character = 0,            line = 80          },          start = {            character = 0,            line = 79          }        },        rangeLength = 1,        text = ""      } },    textDocument = {      uri = "file:///shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart",      version = 78    }  }}
[DEBUG][2023-03-15 02:37:52] .../vim/lsp/rpc.lua:387    "rpc.receive"   {  jsonrpc = "2.0",  method = "window/showMessage",  params = {    message = "Unable to edit document because the file was not previously opened: /shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart",    type = 1  }}

To Reproduce
Steps to reproduce the behavior:

  1. Open a dart file. Note that flutter/lsp is working correctly, eg code actions and warnings
  2. Introduce some deliberate dart errors, eg. delete the class name. Note that the flutter/lsp is working correctly, eg. the error is highlighted
  3. Save the file :w
  4. Attempt to make anothe edit, eg. insert a character
  5. Observe a notification "Unable to edit document because the file was not previously opened: /shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart"
  6. Looking at the lsp.log, I see the same message logged there
  7. Looking at my linux ps, I see that the dart lsp process /shared/sdks/flutter_3.7.1/bin/cache/dart-sdk/bin/dart /shared/sdks/flutter_3.7.1/bin/cache/dart-sdk/bin/snapshots/analysis_server.dart.snapshot --lsp is no longer running
  8. if I reload the file with :e, normal lsp behaviour is resumed with a new dart lsp process

Expected behavior
I expect to be able to carry on editing with an active LSP

Screenshots
If applicable, add screenshots to help explain your problem.

System information

  • OS: Ubuntu 22.04.1 LTS
  • Flutter version:
  • Flutter 3.7.7 • channel stable • https://github.com/flutter/flutter.git
  • Framework • revision 2ad6cd72c0 (6 days ago) • 2023-03-08 09:41:59 -0800
  • Engine • revision 1837b5be5f
  • Tools • Dart 2.19.4 • DevTools 2.20.1
  • Is flutter in $PATH: yes
  • neovim version:NVIM v0.9.0-dev-1184+g0ecb4d725

Additional context
Add any other context about the problem here.

commented

@moonlitknight this and every issue require a truly minimal init.lua, using astronvim or lunar or any other premade configuration is unfortunately not a valid starting point. Please try a minimal configuration without premade configs, just loading this plugin and seeing if this issue is reproducible in vanilla neovim.

I'm going to close this out now but if you are able to reproduce this issue in a minimal environment please post the reproduction steps and I'll try them and re-open this

that, of course, is your prerogrative, however I do consider a virgin AstroVim installation to be a minimal configuration in the modern Neovim world.

I'll keep looking into this as it may well assist others.

As a workaround. I have found that having a second .dart file open suppresses the fault, ie. the fault only manifests when there is only one .dart buffer open.

A question/request if I may...

The analysis_server process I see running is bin/cache/dart-sdk/bin/dart bin/cache/dart-sdk/bin/snapshots/analysis_server.dart.snapshot --lsp. If I run that command with --help, I see a bunch of command line args, and for example, the protocol is --protocol=lsp, not simply --lsp.
Is this correct? Would it be possible to expose a config parameter to allow a user to specify additional argument to the analysis_server process? That way, for example, I could dyamically set the --protocol-traffic-log=<file path> arg to help with debugging , and also any breaking changes to the analysis_server could be handled in config without requiring a code change.

commented

@moonlitknight FWIW the default command was initially taken from neovim core's lspconfig. Which is as canonical as we're likely to get in the neovim ecosystem. This command seemingly works for both myself in daily work as well as presumably other users given it's been unchanged for a while without similar issues (obviously this could have changed in a new flutter version but I'm yet to encounter this).

As to astrovim being a minimal config this is most certainly not the case as as a plugin author I regularly get multiple issues caused by misconfiguration or strange interactions in premade configurations. It is extremely normal to see that users are asked to use a minimal configuration in neovim plugins as well as when reporting to neovim core.

Lastly re changing the command. All arguments that you can pass to the language server can be passed via the lsp configuration in the user settings table. This is explained in more detail in the readme.

On the default command, I agree that a single --lsp argument works. I was more looking at the fact that there is an apparent delta between the hardcoded command line and the latest vesion of analysis_server.dart which might cause problems down the road.

fwiw, I've been looking at the log again, here is an extract ...

[DEBUG][2023-03-15 15:31:38] .../vim/lsp/rpc.lua:284    
"rpc.send"      {  jsonrpc = "2.0",  method = "textDocument/didClose",  params = {    textDocument = {      uri = "file:///shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart"    }  }}
"rpc.send"      {  jsonrpc = "2.0",  method = "textDocument/didOpen",  params = {    textDocument = {      languageId = "dart",      text = "body text",      uri = "file:///shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart",      version = 0    }  }}



"rpc.receive"   {  jsonrpc = "2.0",  method = "window/showMessage",  params = {    message = "Unable to edit document because the file was not previously opened: /shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart",    type = 1  }}
"rpc.send"      {  jsonrpc = "2.0",  method = "textDocument/didChange",  params = {    contentChanges = { {        range = {          ["end"] = {            character = 2,            line = 24          },          start = {            character = 2,            line = 24          }        },        rangeLength = 0,        text = "d"      } },    textDocument = {      uri = "file:///shared/gitlab/chalktel/flutterstarter/lib/uiwidgets/first_ever_run_page.dart",      version = 24    }  }}

Saving the file seems to do a didClose followed by a didOpen. But then the server complains that the file has not been opened. The uri is correct but I noticed that the file was opened with version=0 but then edited with version=24.

I'll sign off now. With my "keep two files open" workaround, I'm up and running so can get back to the day job. My investigation here is more to help others in the future when they encounter the same problem. Many thanks for the plugin and your kind attention.

commented

Those are interesting findings, I've been seeing a few changes to the lsp client in neovim core to try to send didClose notifications when buffers are renamed as well as in some other circumstances. This could very well be an issue of something being a bit broken on nightly nvim by one of those changes.