It is crazy useful and ive no idea how it works.
Server makes me think it is a web service but it works even with like completely local code that is entirely custom and stuff.
All i know is i tend to need to compile the codebase once before it gets the new function definitions.
In: 5
> How can an extension figure out an entirely custom codebase
Literally the same way the compiler can do the same thing. In fact, for a lot of language server implementations, they just use part of the actual compiler (the parser, the lexical, syntax and semantic analyzers), the output of which is [a tree representation](https://en.wikipedia.org/wiki/Abstract_syntax_tree) of all the things in the code, plus the errors the analyzers found.
> How can an extension figure out an entirely custom codebase
Literally the same way the compiler can do the same thing. In fact, for a lot of language server implementations, they just use part of the actual compiler (the parser, the lexical, syntax and semantic analyzers), the output of which is [a tree representation](https://en.wikipedia.org/wiki/Abstract_syntax_tree) of all the things in the code, plus the errors the analyzers found.
Essentially, the IDE builds an index of some sort of your code. It basically takes all of your source code and extracts the outline of the code. Function definitions, global variables, etc.
If you have worked with C/C++ you likely know of an old school version of this. The header files. They basically outline your source file with functions and variables. You define the header file and reference it in other source files to both use it and implement it. The IDE builds something similar to this for any language and uses it to give you the definitions.
> All i know is i tend to need to compile the codebase once before it gets the new function definitions.
Depending on the language you’re using, it sometimes has to do this. Not all languages are structured in a way that makes this easy to keep up to date on the fly. It’s easier to do in languages like Java and C# because they have a fairly strict structure. Javascript can be a lot harder to deal with.
As for why it’s called a server, it’s because it’s implemented as a separate process. It’s like a server that the IDE is talking to, it’s just running locally on your computer. It’s likely using a loopback interface to communicate using TCP/IP, but it doesn’t have to. They do this for a lot of reasons. But one would be to help keep your IDE responsive while the “server” does a bunch of heavy lifting. Or if one crashes, it doesn’t cause the other to crash.
Essentially, the IDE builds an index of some sort of your code. It basically takes all of your source code and extracts the outline of the code. Function definitions, global variables, etc.
If you have worked with C/C++ you likely know of an old school version of this. The header files. They basically outline your source file with functions and variables. You define the header file and reference it in other source files to both use it and implement it. The IDE builds something similar to this for any language and uses it to give you the definitions.
> All i know is i tend to need to compile the codebase once before it gets the new function definitions.
Depending on the language you’re using, it sometimes has to do this. Not all languages are structured in a way that makes this easy to keep up to date on the fly. It’s easier to do in languages like Java and C# because they have a fairly strict structure. Javascript can be a lot harder to deal with.
As for why it’s called a server, it’s because it’s implemented as a separate process. It’s like a server that the IDE is talking to, it’s just running locally on your computer. It’s likely using a loopback interface to communicate using TCP/IP, but it doesn’t have to. They do this for a lot of reasons. But one would be to help keep your IDE responsive while the “server” does a bunch of heavy lifting. Or if one crashes, it doesn’t cause the other to crash.
Essentially, the IDE builds an index of some sort of your code. It basically takes all of your source code and extracts the outline of the code. Function definitions, global variables, etc.
If you have worked with C/C++ you likely know of an old school version of this. The header files. They basically outline your source file with functions and variables. You define the header file and reference it in other source files to both use it and implement it. The IDE builds something similar to this for any language and uses it to give you the definitions.
> All i know is i tend to need to compile the codebase once before it gets the new function definitions.
Depending on the language you’re using, it sometimes has to do this. Not all languages are structured in a way that makes this easy to keep up to date on the fly. It’s easier to do in languages like Java and C# because they have a fairly strict structure. Javascript can be a lot harder to deal with.
As for why it’s called a server, it’s because it’s implemented as a separate process. It’s like a server that the IDE is talking to, it’s just running locally on your computer. It’s likely using a loopback interface to communicate using TCP/IP, but it doesn’t have to. They do this for a lot of reasons. But one would be to help keep your IDE responsive while the “server” does a bunch of heavy lifting. Or if one crashes, it doesn’t cause the other to crash.
The language server is a separate process from the main VS Code process, whose only job is to be fed code and spit out parsed results.
The fact that it is separated in this way is where the “server” part comes from. It’s not a *web* server–it lives entirely on your PC–but it does kind of act like a web server in some ways. Namely, it sits around idling until something asks it to do something, and returns a response once it gets a request. That’s all a “server” technically is.
When you open VS Code, it starts up the lang server on the side. When you open a file, VS Code passes the contents of the file to the lang server, which chews on it for a little bit. When the lang server is done, VS Code gets back a response containing what each piece of code is. VS Code uses that response to decide what colors certain chunks of code should be drawn, what tooltips they should get, whether there are any errors or warnings to complain about, the whole shebang.
The reason the lang server is set up as a separate server instead of just being a part of VS Code proper is for several reasons.
For one, that code crunching can take some time for very large files. If the lang server is going to have to spend a good chunk of time doing its thing, you don’t want the rest of VS Code to lock up and wait for it to finish, you want it to still be usable while it thinks. Separating the lang server out allows this to be possible.
Second, if the lang server is linked to VS Code over a standardized communication protocol, then the actual lang server becomes a black box, where we don’t care what goes on inside. As long as we can talk to it, what it actually does doesn’t matter. So we could, if we wanted, replace the whole lang server with a completely different one, as long as the new one “speaks” the same protocol. This allows us to support multiple programming languages just by replacing the lang server.
Lastly, VS Code uses lang servers that are not proprietary to VS Code. They are open, standalone projects that anyone can use (within license restrictions, which tend to be quite permissive). Since the lang server is basically its own little island, you can thus drop it into any project that knows how to speak to it and it will “just work”.
As to how the lang server itself actually does its thing, that can be quite complex. The thing you will want to research here is “abstract syntax trees” (or “ASTs” for short). The lang server will read incoming code and use a set of rules to build an AST. It is then the resultant AST that VS Code gets back and uses to do things like syntax highlighting, tooltips, error detection, etc.
The language server is a separate process from the main VS Code process, whose only job is to be fed code and spit out parsed results.
The fact that it is separated in this way is where the “server” part comes from. It’s not a *web* server–it lives entirely on your PC–but it does kind of act like a web server in some ways. Namely, it sits around idling until something asks it to do something, and returns a response once it gets a request. That’s all a “server” technically is.
When you open VS Code, it starts up the lang server on the side. When you open a file, VS Code passes the contents of the file to the lang server, which chews on it for a little bit. When the lang server is done, VS Code gets back a response containing what each piece of code is. VS Code uses that response to decide what colors certain chunks of code should be drawn, what tooltips they should get, whether there are any errors or warnings to complain about, the whole shebang.
The reason the lang server is set up as a separate server instead of just being a part of VS Code proper is for several reasons.
For one, that code crunching can take some time for very large files. If the lang server is going to have to spend a good chunk of time doing its thing, you don’t want the rest of VS Code to lock up and wait for it to finish, you want it to still be usable while it thinks. Separating the lang server out allows this to be possible.
Second, if the lang server is linked to VS Code over a standardized communication protocol, then the actual lang server becomes a black box, where we don’t care what goes on inside. As long as we can talk to it, what it actually does doesn’t matter. So we could, if we wanted, replace the whole lang server with a completely different one, as long as the new one “speaks” the same protocol. This allows us to support multiple programming languages just by replacing the lang server.
Lastly, VS Code uses lang servers that are not proprietary to VS Code. They are open, standalone projects that anyone can use (within license restrictions, which tend to be quite permissive). Since the lang server is basically its own little island, you can thus drop it into any project that knows how to speak to it and it will “just work”.
As to how the lang server itself actually does its thing, that can be quite complex. The thing you will want to research here is “abstract syntax trees” (or “ASTs” for short). The lang server will read incoming code and use a set of rules to build an AST. It is then the resultant AST that VS Code gets back and uses to do things like syntax highlighting, tooltips, error detection, etc.
The language server is a separate process from the main VS Code process, whose only job is to be fed code and spit out parsed results.
The fact that it is separated in this way is where the “server” part comes from. It’s not a *web* server–it lives entirely on your PC–but it does kind of act like a web server in some ways. Namely, it sits around idling until something asks it to do something, and returns a response once it gets a request. That’s all a “server” technically is.
When you open VS Code, it starts up the lang server on the side. When you open a file, VS Code passes the contents of the file to the lang server, which chews on it for a little bit. When the lang server is done, VS Code gets back a response containing what each piece of code is. VS Code uses that response to decide what colors certain chunks of code should be drawn, what tooltips they should get, whether there are any errors or warnings to complain about, the whole shebang.
The reason the lang server is set up as a separate server instead of just being a part of VS Code proper is for several reasons.
For one, that code crunching can take some time for very large files. If the lang server is going to have to spend a good chunk of time doing its thing, you don’t want the rest of VS Code to lock up and wait for it to finish, you want it to still be usable while it thinks. Separating the lang server out allows this to be possible.
Second, if the lang server is linked to VS Code over a standardized communication protocol, then the actual lang server becomes a black box, where we don’t care what goes on inside. As long as we can talk to it, what it actually does doesn’t matter. So we could, if we wanted, replace the whole lang server with a completely different one, as long as the new one “speaks” the same protocol. This allows us to support multiple programming languages just by replacing the lang server.
Lastly, VS Code uses lang servers that are not proprietary to VS Code. They are open, standalone projects that anyone can use (within license restrictions, which tend to be quite permissive). Since the lang server is basically its own little island, you can thus drop it into any project that knows how to speak to it and it will “just work”.
As to how the lang server itself actually does its thing, that can be quite complex. The thing you will want to research here is “abstract syntax trees” (or “ASTs” for short). The lang server will read incoming code and use a set of rules to build an AST. It is then the resultant AST that VS Code gets back and uses to do things like syntax highlighting, tooltips, error detection, etc.
Latest Answers