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.

Sign up for GitHub

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

Jump to bottom

Fix typos - initialization.md #954

Merged
merged 1 commit into from Jul 27, 2023
Merged

Fix typos - initialization.md #954

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions guides/initialization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,9 +15,9 @@ When launching the elixir_ls server using the scripts, the initialization steps

The Language Server Protocol and Debugger Adapter Protocol mandate that all communication between the client and the server is made using UTF-8 encoded JSON-RPC based protocol. See [LSP Base Protocol](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#baseProtocol) and [DAP Base Protocol](https://microsoft.github.io/debug-adapter-protocol/overview/#base-protocol). BEAM character IO is UTF-8 as default currently (was latin1 in the past which is a type of UTF-16). So, in order to have this kind of encoding/decoding out of the way, it first overrides two processes started by all BEAM instances: `:user` and `:stderr` with `ElixirLS.Utils.OutputDevice` in `ElixirLS.Utils.WireProtocol` module.

The first process is the name for standard IO while the second is the the standard error. They are both IO servers, that means, `:gen_server` implementations that follows the [IO protocol](http://erlang.org/doc/apps/stdlib/io_protocol.html).
The first process is the name for standard IO while the second is the standard error. They are both IO servers, that means, `:gen_server` implementations that follow the [IO protocol](http://erlang.org/doc/apps/stdlib/io_protocol.html).

The servers reads and decodes protocol messages in `ElixirLS.Utils.PacketStream`. Output messages are sent via `ElixirLS.LanguageServer.JsonRpc` or `ElixirLS.Debugger.Output`.
The servers read and decode protocol messages in `ElixirLS.Utils.PacketStream`. Output messages are sent via `ElixirLS.LanguageServer.JsonRpc` or `ElixirLS.Debugger.Output`.

## Starts Mix

Expand All @@ -37,9 +37,9 @@ The first one is the server itself `ElixirLS.LanguageServer.Server`. This is a n
- map of requests to match with responses;
- current open files in the client;

Upon start the server initializes its state with defaults (mostly empty values) and then waits for messages. It is important to know that up to now the server does not have a project directory set (nor its root uri).
Upon start, the server initializes its state with defaults (mostly empty values) and then waits for messages. It is important to know that up to now the server does not have a project directory set (nor its root uri).

After this `GenServer` is started, the next in line is the `ElixirLS.LanguageServer.JsonRpc` server. This is the one responsible for handling JSON RPC requests and responses. It is another `GenServer` that receives and sends packets through standard IO and standard error set on the first step of initialization.
After this `GenServer` is started, the next in line is the `ElixirLS.LanguageServer.JsonRpc` server. This is the one responsible for handling JSON-RPC requests and responses. It is another `GenServer` that receives and sends packets through standard IO and standard error set on the first step of initialization.

## Overrides default Mix.Shell

Expand All @@ -64,7 +64,7 @@ Any requests coming from a LSP client will now follow this path:
- The `ElixirLS.Utils.PacketStream` will read input from standard IO in the already mentioned `Stream.resource/3` call;
- Each request has a header and a body. Both will be parsed to maps;
- The request will be handled by `ElixirLS.LanguageServer.JsonRpc.receive_packet/1`;
- A match is made with the request body content to check if its a:
- A match is made with the request body content to check if it's a:
- [notification](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#notificationMessage)
- [request](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#requestMessage)
- [response with/without response_errors](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#responseMessage)
Expand Down Expand Up @@ -126,6 +126,6 @@ Here is the point in time where it will build the [PLT (a Persistent Lookup Tabl

There are many things done in this module. It tries to be smart about analyzing only the modules that have changed. It does that by first checking the integrity of the PLT and then loading all modules from the PLT using `:dialyzer_plt.all_modules/1`.

If it finds that there is a difference, than it calculates this difference (using `MapSet`) to separate stale modules from non-stale. Then it delegates do the `ElixirLS.LanguageServer.Dialyzer.Analyzer` module for the proper analysis run.
If it finds that there is a difference, than it calculates this difference (using `MapSet`) to separate stale modules from non-stale. Then it delegates to the `ElixirLS.LanguageServer.Dialyzer.Analyzer` module for the proper analysis run.

In the end it will publish a message that the analysis has finished, which will be delegated all the way back to the server module. There it handles the results accordingly and finally it will be ready to introspect code.