Can someone ELI5 lsp?

Can anyone help me understand LSP and why I’d want it? My probably wrong understanding is that it just moves things like syntax highlighting and tab complete off my local config and onto a remote server. Is that it? If so, what is the appeal? I see nothing but downsides: - what if I’m not online or having network issues? - remote has to by definition be slower than local - I don’t control configuration - I don’t control updates/changes - at the whims of their choices of tools Is it only used in corporate environments? Am I missing something here?

> onto a remote server More likely a local server. Where server basically means: a program that receives requests in a (hopefully) universal grammar and responds in the same fashion Your client (`lsp-mode` or `eglot` typically) requests things, the server replies and the client decides what to do with those responses. A few examples of responses: - Character position(s) where to display inline feedback - Payload containing changes to apply: when you rename a symbol in the project for instance, or when you insert an import at the top of the file - A text representation of a documentation for the current point position

> More likely a local server. So now I have to maintain my own server? What’s the benefit? I can do all these things locally. What do I gain to offset these added complications and downsides?

All that's happening is that a program is running on your machine; that program takes requests from other programs on your machine, and provides a response. There are, more likely than not, many such programs running on your machine, called something like 'services' or 'daemons'. There's no more maintenance you have to do than upgrading it like you would any other bit of software on your machine. The benefit is that a language server for a particular programming language can focus on the characteristics of the language, and not have to worry about the specific characteristics of the editor the programmer is using, and vice versa. (E.g. the maintainers of the language server for the 'Blub' programming language don't need to worry about how Emacs or Vim or whatever work.) This can lead to better support from both sides for developing in that language.

LSP servers implement that feature better than anyone has ever been able to in lisp. It's basic separation of concerns. > what if I’m not online or having network issues? 99% of the time it's a local server > remote has to by definition be slower than local Not necessarily in any way that matters. > I don’t control configuration … why not? > I don’t control updates/changes … why not? > at the whims of their choices of tools Huh? You seem to have some funny ideas of what a "server" is or must be. It's really just "separate process that answers requests".

I'm guessing you would be amazed how many so called "servers" run on your machine currently

Well as I said I probably had a mistaken understanding. It's called "server protocol", I think I can be excused for thinking it means an actual server, not just a local process. Thanks for clarifying. So ok this solves a lot of the concerns I have, but I'm still failing to understanding the benefit.

The notion of a 'server' as a physical thing comes from "a machine dedicated to running a server process", where a 'server' is just a program that serves responses to requests from clients. As for the benefit, i already mentioned it in [my earlier comment](https://www.reddit.com/r/emacs/comments/ufy92x/comment/i6wchpp/): > The benefit is that a language server for a particular programming language can focus on the characteristics of the language, and not have to worry about the specific characteristics of the editor the programmer is using, and vice versa. (E.g. the maintainers of the language server for the 'Blub' programming language don't need to worry about how Emacs or Vim or whatever work.) This can lead to better support from both sides for developing in that language. For example, on the editor side, people don't need to spend time getting the editor to accurately 'understand' how the language works and implementing the appropriate support again and again and again for each editor. In other words, it can greatly reduce the amount of work required to implement and maintain support for a particular language in a particular editor. If an editor can speak LSP, it automatically has access to information for things like syntax highlighting, jumps to definitions/references, documentation for various aspects of the language, etc.

I've found [this post](https://matklad.github.io//2022/04/25/why-lsp.html) very good when explaining the concept of LSP to new people. Hopefully it'll help you too!

To sum it up : maintainjing syntax checking, completion is a harf and computationally expensive task. Elisp does not have multithreading, so it slows Everything down. If you can't run a dedicated thread, you can use a process, hence a language server. It can communicare with your program in several ways, most editor had their own method / protocol. Everything changed a few years back when VSCode introduced a standardized REST API, called LSP. which means in theory that any editor implementing the API can launch a completion program as needed to communicate with it and get completion working. This is why emacs has not completion on par with the reference since it can use VSCODE's own language server. Mist of the time you only install the server once and lsp mode will launch it automatically and pass it the appropriate stuff.

While both are commonly called "servers", don't confuse a server program with the hardware it runs on. See this quote from [Wikipedia](https://en.wikipedia.org/wiki/Client%E2%80%93server_model) (emphasis mine): > Client-server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, ***but both client and server may reside in the same system***. This is the same meaning used when discussing [`emacsclient` and the Emacs server](https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html), which, as far as I know, can only be run locally.

**[Client–server model](https://en.wikipedia.org/wiki/Client–server_model)** >Client-server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server host runs one or more server programs, which share their resources with clients. A client usually does not share any of its resources, but it requests content or service from a server. ^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/emacs/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)

I never managed to get Cedet, rtags, and whatever to work for me in Emacs, so I just programmed in C++ in KDevelop, NetBeans, and other IDEs where things just worked. When VSCode matured, I used that. But, ironically, as LSP has matured, I am back in Emacs. It makes a lot of sense to out-source to a LSP server. It keeps the configuration clean, and it just works. I spent half an hour getting a full-fledged C++ / CMake IDE up and running using the clangd LSP server and the cmake LSP server. It works even better than VSCode itself, to be honest. ​ I have been using Emacs for years, but only for writing / editing text, but now I am using it for programming. Using dedicated, language-parsing, syntax aware servers makes a ton of sense. Before LSP I was wrestling with a multitude of Emacs packages, and never quite managed to get it to work. So, yes, LSP is great. :) Think of it as a daemon, a service, an expert imp slaving away :D

> an actual server, not just a local process. Thanks for clarifying. Yeah, this is a common misconception, but a misconception all the same. :)

> LSP servers implement that feature better than anyone has ever been able to in lisp. (I'm not sure what "that feature" refers to specifically, probably code completion, but let's talk about all the features LSP provides.) Really? I don't use LSP that much yet (but I finally installed eglot and a couple of servers a few days ago: clojure-lsp, lua-lsp and digestif), but my impression is that it offers only a subset of what Emacs offers for Emacs Lisp or what Slime/Sly offer for Common Lisp. In particular, it seems that LSP can only find definitions and references, and show documentation for identifiers, but doesn't do any sending of code to a compiler or interpreter for evaluation. Also some LSP servers are actually written in a Lisp dialect, like clojure-lsp. (I'm not sure why clojure-lsp exists, since it seems to provide a subset of the functionality of the older Cider package.) Did you mean maybe that for many languages no-one has bothered to attempt to implement comparable functionality in Lisp? That I would totally believe. But when people have attempted to do it in a Lisp, like Slime or Cider, I think the results are still superior to LSP.

It's about good autocomplete and syntax checking for languages other than lisp. A syntax checker for c++ written in lisp would have to implement complete understanding of c++ in lisp. While the clangd language server uses actual c++ compiler internals to tell emacs about your syntax.

> a remote server I think you can be excused for this misconception. That was my first impression when I heard of it. But no, it's not necessarily a remote server. Maybe a better name would have been "language daemon protocol". It's just a running process that your editor talks to for direction on how to handle a particular language. But it's not necessarily a rabbit hole you need to go down. Emacs already has great built-in support for many languages. You don't need to bother with LSP unless you feel there are features you need that you're missing out on.

In addition to the other good answers here, you generally don't have to install anything manually. `lsp-mode` will auto-install and run the servers for you with no effort on your part. It then will analyze your code for you. E.g. with a C/C++ project it will perform the build steps and show you compilation errors inline, and even unhighlight disabled `#ifdef` blocks etc.. With interpreted code like Typescript it'll perform code analysis and tell you for instance that `foo['static_string']` is invalid because `static_string` is not a valid field of `foo`, or perhaps it'll tell you you're treating the result as the wrong type. These are all sophisticated analyses that there's no way Emacs could / should do itself. Instead it makes use of the same servers VS Code etc. use to do the work, and Emacs just displays the results. This stuff is an absolute delight and significant accelerator to development. I write so much more code that "just works" first time as a result. The errors left at first execution are generally logic and design errors.

I think most syntax highlighting is still done with regular expressions or something like tree-sitter. I know that version 3.16 of the language server protocol now has a feature called "semantic tokens" where the language server can provide additional semantic information that can improve syntax highlighting, but I don't think this is something that a lot of current language servers support yet.

Oh interesting, thanks. (Particularly as someone who's implemented a major mode and its syntax highlighting.)