Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSCode save takes a lot of time #392

Closed
cvkmohan opened this issue Mar 10, 2024 · 9 comments
Closed

VSCode save takes a lot of time #392

cvkmohan opened this issue Mar 10, 2024 · 9 comments

Comments

@cvkmohan
Copy link

image
I have formatonsave on in vscode. Now, it is taking a long time - sometimes upto a minute or more. It was not the case earlier.

@mhanberg
Copy link
Collaborator

Can you check the output panel for errors

@cvkmohan
Copy link
Author

image
Could not find any errors. This is the message I am getting when I changed the setting to verbose on server communication

@mhanberg
Copy link
Collaborator

gotcha, there must be something weird with formatting

I don't think i've personally attempted to save a heex file (i use the sigil), i'll attempt to reproduce

@rdlu
Copy link

rdlu commented Mar 11, 2024

I have something related. I just updated nextls, but I'm using neovim.

Heex files sometimes takes a long time, but after a while they become instantly formatted, and some times I'm under impression that it's not triggering at at all.

At the first save it consumes a lot of cpu and I can listen the fan blowing hard for a few to several seconds, but I was not able to pinpoint anything using btop.

I did Elixir nextls uninstall and it improved after reinstalling, even with the auto update telling me it was successful.

The only strange things I seeing are from other tools, like tail, when I was trying to follow the lsp logs:

tail: inotify cannot be used, reverting to polling: Too many open files even with fs.inotify.max_user_watches = 524288

Thanks for your efforts! Since last week I using nextls as my primary option, including completion. I must say it's more stable than using the old lsp, like in presence of errors and crashing with incomplete code.

Let me know if you need any extra logs, looking at first glance it doesn't look like I have any errors on it as well.

Actually I found one WARN. If I open and save an heex file before any .ex:

[WARN][2024-03-11 10:19:34] ...lsp/handlers.lua:537     '** (ErlangError) Erlang error: "KeyError during metadata build pre:\\nkey :line not found in: []\\nast node: {{:., [], [{:__aliases__, [alias: false], [:String, :Chars]}, :to_string]}, [], [{:svg, [closing: [line: 5, column: 30], line: 5, column: 13], [\\"information\\"]}]}"\n    (elixir 1.16.1) lib/keyword.ex:599: Keyword.fetch!/2\n    (elixir_sense 2.0.0) lib/elixir_sense/core/metadata_builder.ex:1438: ElixirSense.Core.MetadataBuilder.pre/2\n    (elixir_sense 2.0.0) lib/elixir_sense/core/metadata_builder.ex:102: ElixirSense.Core.MetadataBuilder.safe_call_pre/2\n    (elixir 1.16.1) lib/macro.ex:640: anonymous fn/4 in Macro.do_traverse_args/4\n    (stdlib 5.2) lists.erl:1706: :lists.mapfoldl_1/3\n    (stdlib 5.2) lists.erl:1707: :lists.mapfoldl_1/3\n    (elixir 1.16.1) lib/macro.ex:605: Macro.do_traverse/4\n    (stdlib 5.2) lists.erl:1706: :lists.mapfoldl_1/3\n    (elixir 1.16.1) lib/macro.ex:605: Macro.do_traverse/4\n    (elixir_sense 2.0.0) lib/elixir_sense/core/metadata_builder.ex:46: ElixirSense.Core.MetadataBuilder.build/1\n    (language_server 0.20.0) lib/language_server/parser.ex:360: ElixirLS.LanguageServer.Parser.do_parse/2\n    (language_server 0.20.0) lib/language_server/parser.ex:222: anonymous fn/3 in ElixirLS.LanguageServer.Parser.handle_info/2\n'
[WARN][2024-03-11 10:19:34] ...lsp/handlers.lua:537     '** (ErlangError) Erlang error: "KeyError during metadata build post:\\nkey :line not found in: []\\nast node: {:=, [], [{:arg0, [], EEx.Engine}, nil]}"\n    (elixir 1.16.1) lib/keyword.ex:599: Keyword.fetch!/2\n    (elixir_sense 2.0.0) lib/elixir_sense/core/metadata_builder.ex:1749: ElixirSense.Core.MetadataBuilder.post/2\n    (elixir_sense 2.0.0) lib/elixir_sense/core/metadata_builder.ex:129: ElixirSense.Core.MetadataBuilder.safe_call_post/2\n    (stdlib 5.2) lists.erl:1706: :lists.mapfoldl_1/3\n    (elixir 1.16.1) lib/macro.ex:605: Macro.do_traverse/4\n    (elixir_sense 2.0.0) lib/elixir_sense/core/metadata_builder.ex:46: ElixirSense.Core.MetadataBuilder.build/1\n    (language_server 0.20.0) lib/language_server/parser.ex:360: ElixirLS.LanguageServer.Parser.do_parse/2\n    (language_server 0.20.0) lib/language_server/parser.ex:222: anonymous fn/3 in ElixirLS.LanguageServer.Parser.handle_info/2\n'

But if I open an ex file, save it, then resume my work with .heex, these warnings stop showing.

@mhanberg
Copy link
Collaborator

Please check the log file at .elixir-tools/nextls.log

@mhanberg
Copy link
Collaborator

The log you shared is from ElixirLS, not Next LS. Please make sure you are only using one and try to reproduce again.

@rdlu
Copy link

rdlu commented Mar 12, 2024

(op: sorry for stealing a vscode thread)

Yeah you're right:

Language client log: /home/rdlu/.local/state/nvim/lsp.log
 Detected filetype:   elixir
....

Client: elixirls (id: 3, bufnr: [3])
 	filetypes:       elixir, eelixir, heex, surface
 	autostart:       true
 	root directory:  /home/rdlu/Projects/test
 	cmd:             elixir-ls
 
 Client: Next LS (id: 5, bufnr: [3])
 	filetypes:       
 	autostart:       false
 	root directory:  Running in single file mode.
 	cmd:             /home/rdlu/.cache/elixir-tools/nextls/bin/nextls --stdio

Even with elixirls disabled, removing references from Mason, lazyvim extras, etc, the lsp info is saying that elixirls is still running:

~/.config/nvim/lua/plugins/elixir.lua

....
        elixirls = {
          enable = false,
        },
...

I'll try to open an issue on elixir-tools.nvim instead and keep observing the logs.

They are actually inside my project folder .elixir-tools/next-ls.log with a dash.

And I have only several lines of this with heex or ex:

07:47:05.399 [debug] sent notification server -> client textDocument/publishDiagnostics

But inotify exhaustion is happening a lot more whenever I'm editing a single heex file. With only ex files it's happening less.

Thanks!

@cvkmohan
Copy link
Author

This problem is persisting.
image
This is all that I can see in the log. But, it is taking a long time to save.
I wanted to report because, this is a fresh installation. WSL, Ubuntu 22.04, asdf, elixir - everything freshly installed.

@mhanberg
Copy link
Collaborator

I believe #401 should close out this issue, I will likely release it in v0.20.2, please update and let me know if you can still reproduce.

I'll close the issue if I don't hear back in a while, but feel free to comment and I'll re-open

@mhanberg mhanberg closed this as completed Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants