Should not execute config/runtime.exs about next-ls HOT 17 CLOSED

IIRC the compilation was long time finished. Plus listing the current file symbols works well.

I'm leaving the office for now but I can run any tests you want later.

Erlang/OTP 25 [erts-13.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]

Elixir 1.14.0 (compiled with Erlang/OTP 25)

from next-ls.

I think you will need to evaluate the compile-time config files, otherwise it is possible that some user modules do not compile at all. (For instance, anything that call Application.compile_env! is at risk.

So I believe it is just the runtime.exs that should be skipped.

A very very dirty solution would be to redefine the Mix.Tasks.Loadconfig module, with a no-op function as load_runtime/1.

What is strange is that NextLS is not supposed to boot the user application, is it? If I raise in my runtime.exs and run mix compile it works, because it is not evaluated at compile-time. So why does NextLS evaluates that file instead of its own configuration?

from next-ls.

I think you will need to evaluate the compile-time config files, otherwise it is possible that some user modules do not compile at all.

Yes, I was thinking that even dependencies sometimes need app config when compiling, so they have to run.

What is strange is that NextLS is not supposed to boot the user application, is it?

Next LS starts your project with a bunch of flags to not actually start anything, just load your code and deps into a VM that is then connected to Next LS via distributed erlang.

from next-ls.

Would it be imaginable that NextLS starts a custom application in that VM, just adding the elixirc_paths of the user project to its own paths, dynamically or in mix.exs. That way you do not need flags because the mod in .app is not the user's.

That would sill require to copy the config files or something...

from next-ls.

I think a workaround for you right now would be to wrap your entire runtime.exs file in if not System.get_env("NEXT_LS_PARENT_PID") do

this env var is set by Next LS, so if it is present, it means you are in Next LS and can avoid executing anything

from next-ls.

I published 0.5.2 that sets an LSP variable, so you can do if System.get_env("LSP") do

from next-ls.

Using NEXT_LS_PARENT_PID works with a custom run with TCP but it does not work with the default stdio adapter (and letting the extension start it itself)

[Error - 13:06:35] Client NextLS: connection to server is erroring. Shutting down server.
[Error - 13:06:35] Stopping server failed
Error: Client is not running and can't be stopped. It's current state is: starting

I'm using vscode and the last extension version is one week old so I did not try with the "LSP" variable.

Besides, when I start the tool from a shell ( NEXTLS_VERSION=0.5.1 /home/lud/.vscode/extensions/elixir-tools.elixir-tools-0.2.2/bin/nextls --port 9999 ) the vscode output shows that the app is compiling, an I can have the current file symbols, but there is no code formatting nor go-to-definition and the workspace symbols do not work, they always display the symbols for the same module. Not sure if it is expected or related to the runtime.exs problem though.

( Same with NEXTLS_VERSION=0.5.2 )

from next-ls.

The extension version is not tied to the NextLS version. When you start it normally it will fetch the latest version of NextLS.

With regard to your last statement, did you let it finish compiling? Or were those features not working while it was compiling?

from next-ls.

Can you remind me what your exact elixir and OTP versions are?

from next-ls.

@lud-wj

Let me know if you get to try this out again and if it fixed your issues.

from next-ls.

Hello, I see a vscode version from 4 days ago. Same errors on my side, telling that the server cannot be started

It works though, if I run the server manually and connect with TCP with this version of the extension:

NEXTLS_VERSION=0.5.4 /home/lud/.vscode/extensions/elixir-tools.elixir-tools-0.3.0/bin/nextls --port 9999

from next-ls.

The vscode extension version is not tied to the next ls version. It always fetches the latest version of next ls automatically.

But, you now can set the version from the extension. Could you try that just to be sure?

from next-ls.

I can confirm that it works now with this configuration:

  "elixir-tools.credo.enable": false,
  "elixir-tools.nextls.enable": true,
  "elixir-tools.nextls.version": "0.5.4",

Though "Go To Definition" works only for a few cases (full module name, no aliases, and only for some modules). Is there a way to debug that?

from next-ls.

Delete the .elixir-tools folder so it forces it to rebuild the lookup table.

from next-ls.

No changes unfortunately. I can try to debug to see why, I do not know when though.

from next-ls.

Make sure they aren't anything in these cases that haven't been implemented yet: https://www.elixir-tools.dev/next-ls/#definition

from next-ls.

Ah yes, that should be it. Thank you.

from next-ls.