Perry E. Metzger schrieb am Di., 11. Apr. 2017 um 18:28 Uhr: > Microsoft has invented an interesting new protocol for IDEs > and code editors to talk to language tools (like compilers) to do > things like smart autocompletion, jumping to code definitions, and the > like. > > The idea is that compilers and similar tools generally know a lot > about the structure of a language and can provide help to an editor as > an external service, so the editor doesn't need to handle parsing, > symbol tables, etc. for the language on its own. The editor can just > ask the compiler or language tool for the information when it needs > it. > > The protocol is open and they have no intellectual property claims on > it. It is JSON based and should be straightforward to support. > > A general description is at: > > http://langserver.org/ > > And detailed protocol information is at: > > https://github.com/Microsoft/language-server-protocol > > It was originally designed for their "Roslyn" C# compiler (which is > free software, it's Apache licensed) to integrate with their own > editors and IDEs, but other compiler projects and editors seem to be > adopting the thing. There are now language servers people have built > for a lot of languages, and there's support appearing for the > protocol in a bunch of editors. > > I'm mentioning this here because I think the Emacs community would be > interested in this capability, though I suspect that it would also be > really neat if GCC developed a language server for C and C++. > > I recall that a while ago, RMS had a lot of problems with the idea > of opening up GCC in ways that might have made it possible for people > to use it too much for proprietary compilers. Using the Language > Server Protocol, it should be possible for GCC and other free > language tools to talk to a variety of IDEs and Editors (including, I > hope, Emacs) to allow advanced modern code editing _without_ the > sorts of risks he was worried about. > I agree and think that language servers are very promising and we should have strong support for the protocol in Emacs (preferably even in core). They neatly solve the problem of having to implement support for each and every language in Elisp.