Language Server Protocol (LSP)

LSP was introduced by Microsoft (originally for VS Code) and is now an open specification. Before it, every editor needed bespoke integration for every language, an M-by-N problem: M editors times N languages. LSP collapses that to M plus N. A language server understands one language deeply, and any LSP-speaking client can consume it. That is why a single rust-analyzer, gopls, or typescript-language-server works in VS Code, Neovim, Emacs, and Zed alike.

Communication runs over JSON-RPC, typically across stdio or a socket. The client sends requests like textDocument/definition, textDocument/references, textDocument/rename, and textDocument/hover. The server responds with locations, edits, or symbol information. The server also pushes notifications, most importantly textDocument/publishDiagnostics, which is how the squiggly errors and warnings appear in your editor. Capabilities are negotiated during an initialize handshake, so a client only uses features the server actually supports.

The key property for tooling is that LSP answers are semantic, not textual. A "find references" result is the set of places that actually resolve to the same symbol, accounting for scope, imports, and types, rather than a text match for the same name. A workspace rename returns a coordinated set of edits across files that keep the program compiling. This is the same machinery that powers IDE refactors.

Companion specifications extend the model: the Debug Adapter Protocol (DAP) does for debuggers what LSP does for language features, and the Build Server Protocol (BSP) covers build systems. Most mainstream languages now ship a maintained language server, and registries like Mason package hundreds of them for easy installation.