3 ms·

I've read a bunch of articles about LSP, and some of the docs, but still not entirely sure what it is. I mean, abstractly I understand, but to truly understand

I've read a bunch of articles about LSP, and some of the docs, but still not entirely sure what it is. I mean, abstractly I understand, but to truly understand what it's capable of doing and when I might need to use it... Does anyone have any good pointers?

kstrauser 3y ago
At a high level, it’s a standard way for an editor to ask another program for information about a source code file: What are the function definitions here? What are the available completions for this text? What errors are there? Can you reformat this in standard way? Where is the thing one line 23, row 41 defined? Instead of every single editor having to understand C and Python and JavaScript and Rust and SQL and Ruby, they only have to know how to talk to a language server using a standard protocol. And if you’re writing a new language, you can make a language server for it, and then every editor that knows how to use LSP can be used to comfortably write code in that new language. The old way is that M editors want to support N languages, someone has to write M times N language parsers. With LSP, they can write N. That’s way less work.
ww520 3y ago
LSP stands for Language Server Protocol. It's a communication protocol between the clients (text editors, debuggers, source viewers, etc) and the language servers. Typically a language compiler runs over the source files and terminates once it's done. All the compilation states are gone. The language server is the compiler itself running for a long time; its aim is to maintain the compiled states of the source files alongside of the editing session in the editor client. It's ready to answer requests from the editor in regarding the source code. E.g. The editor loads a source file. It sends a LSP request to the language server saying the file is opened. The language server would compile the file and maintain its compiled states. The compilation process might involve other source files as well. The language server reports any errors or warnings back to the editor. The editor shows them to the user right the way. The user modifies a function and hits save. The editor sends a file-changed request to the language server. It recompiles the file and sends back any errors or warnings. The user places the cursor at a function call and issues the jump-to-definition command. The editor sends a LSP request to the language server to look up the location of the definition of the function. The language server has all the compiled states of the source files and knows where the function definition is. It sends back the target location (file and line number). The editor can switch to the target file and jump to the line number. LSP defines a whole bunch of these requests and responses (e.g. looking up the type of a variable, definition of a value, auto-completion suggestion of function parameters, etc). A language server for a language can implement these and suddenly all the clients that talk LSP can utilize the features.
- misja111 3y ago
  Thanks for the very clear explanation! Where does the language server typically run? Does it run on some remote server or as a separate process next to your editor on your local machine?
  - maccard 3y ago
    Honestly, you should read some of the docs [0] if these are the sorts of questions you're asking. [0] https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/
  - ww520 3y ago
    The language server typically runs in another process alongside of the editor on the same machine. Usually it is the editor that spawns off a new process of the language server and connects to it. The editor can launches multiple language servers, one per a project of a particular language. E.g. when the editor opens a Rust file, it would launch the Rust language server and connects to it. When it opens a Javascript file, it would launch the Javascript language server and connects to it. Running the language server remotely would require more setup. The editor and the language server need to look at the same file, so you have to sync the changes to the file locally and remotely somehow. Also the editor might not be able to automatically launch a remote language server. You have to start it manually and make the editor connect to it manually. It's just not a smooth UX.
- DiabloD3 3y ago
  > debuggers That's where the sibling protocol, DAP, comes in. Rest of this is a good simple explanation on what LSP does, otherwise.
  - ww520 3y ago
    Yes, DAP is another protocol for remote debugging. I was thinking for debuggers that can already debug locally but want to show type info or various definition of entities in the source code.
School-Cotton 3y ago
What do you typically program in?
globular-toast 3y ago
For a more succinct answer, I use it for three things: jumping to the definition of a symbol, auto completion of symbols and keywords and showing documentation. None of this is new. We've had TAGS tables forever. Certain editors would provide the rest for certain languages in language-specific ways. LSP is just a general solution to the any editor/any language problem. It seems to work at least as good and often better than the custom solutions before.
- misja111 3y ago
  > It seems to work at least as good and often better than the custom solutions before. The standardization that LSP brings is nice, but from a user's point of view it's pretty terrible compared to existing custom solutions. At least for the few languages I tried; Scala and Haskell. The feature set supported was very small compared to what existing integrated editors supported, it was slower and less reliable.
  - globular-toast 3y ago
    Yeah, I should have added for some languages. For me, Python is better with LSP than it was with Elpy, the custom Python support for Emacs. But it's certainly not going to beat something lime SLIME for Common Lisp and obviously not editing Emacs Lisp within Emacs.
    - NoGravitas 3y ago
      Yeah, I was going to come say something like this. LSP is much better than the status quo for most languages, but SLIME is so much better there's just no comparison.

kstrauser 3y ago

At a high level, it’s a standard way for an editor to ask another program for information about a source code file: What are the function definitions here? What are the available completions for this text? What errors are there? Can you reformat this in standard way? Where is the thing one line 23, row 41 defined? Instead of every single editor having to understand C and Python and JavaScript and Rust and SQL and Ruby, they only have to know how to talk to a language server using a standard protocol. And if you’re writing a new language, you can make a language server for it, and then every editor that knows how to use LSP can be used to comfortably write code in that new language. The old way is that M editors want to support N languages, someone has to write M times N language parsers. With LSP, they can write N. That’s way less work.

ww520 3y ago

LSP stands for Language Server Protocol. It's a communication protocol between the clients (text editors, debuggers, source viewers, etc) and the language servers. Typically a language compiler runs over the source files and terminates once it's done. All the compilation states are gone. The language server is the compiler itself running for a long time; its aim is to maintain the compiled states of the source files alongside of the editing session in the editor client. It's ready to answer requests from the editor in regarding the source code. E.g. The editor loads a source file. It sends a LSP request to the language server saying the file is opened. The language server would compile the file and maintain its compiled states. The compilation process might involve other source files as well. The language server reports any errors or warnings back to the editor. The editor shows them to the user right the way. The user modifies a function and hits save. The editor sends a file-changed request to the language server. It recompiles the file and sends back any errors or warnings. The user places the cursor at a function call and issues the jump-to-definition command. The editor sends a LSP request to the language server to look up the location of the definition of the function. The language server has all the compiled states of the source files and knows where the function definition is. It sends back the target location (file and line number). The editor can switch to the target file and jump to the line number. LSP defines a whole bunch of these requests and responses (e.g. looking up the type of a variable, definition of a value, auto-completion suggestion of function parameters, etc). A language server for a language can implement these and suddenly all the clients that talk LSP can utilize the features.

misja111 3y ago
Thanks for the very clear explanation! Where does the language server typically run? Does it run on some remote server or as a separate process next to your editor on your local machine?
- maccard 3y ago
  Honestly, you should read some of the docs [0] if these are the sorts of questions you're asking. [0] https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/
- ww520 3y ago
  The language server typically runs in another process alongside of the editor on the same machine. Usually it is the editor that spawns off a new process of the language server and connects to it. The editor can launches multiple language servers, one per a project of a particular language. E.g. when the editor opens a Rust file, it would launch the Rust language server and connects to it. When it opens a Javascript file, it would launch the Javascript language server and connects to it. Running the language server remotely would require more setup. The editor and the language server need to look at the same file, so you have to sync the changes to the file locally and remotely somehow. Also the editor might not be able to automatically launch a remote language server. You have to start it manually and make the editor connect to it manually. It's just not a smooth UX.
DiabloD3 3y ago
> debuggers That's where the sibling protocol, DAP, comes in. Rest of this is a good simple explanation on what LSP does, otherwise.
- ww520 3y ago
  Yes, DAP is another protocol for remote debugging. I was thinking for debuggers that can already debug locally but want to show type info or various definition of entities in the source code.

School-Cotton 3y ago

What do you typically program in?

globular-toast 3y ago

For a more succinct answer, I use it for three things: jumping to the definition of a symbol, auto completion of symbols and keywords and showing documentation. None of this is new. We've had TAGS tables forever. Certain editors would provide the rest for certain languages in language-specific ways. LSP is just a general solution to the any editor/any language problem. It seems to work at least as good and often better than the custom solutions before.

misja111 3y ago
> It seems to work at least as good and often better than the custom solutions before. The standardization that LSP brings is nice, but from a user's point of view it's pretty terrible compared to existing custom solutions. At least for the few languages I tried; Scala and Haskell. The feature set supported was very small compared to what existing integrated editors supported, it was slower and less reliable.
- globular-toast 3y ago
  Yeah, I should have added for some languages. For me, Python is better with LSP than it was with Elpy, the custom Python support for Emacs. But it's certainly not going to beat something lime SLIME for Common Lisp and obviously not editing Emacs Lisp within Emacs.
  - NoGravitas 3y ago
    Yeah, I was going to come say something like this. LSP is much better than the status quo for most languages, but SLIME is so much better there's just no comparison.