Hacker News Reader

Comment by mikewhy | Hacker News Reader

> felt like something we all should of figured out years and years ago

Before language server there was YouCompleteMe, a plugin for Vim that had the same ideas. It was eventually ported to other editors, but LSP wasn't far behind and eventually took over.

I'm no good with Google Trends, but here they are: https://trends.google.com/trends/explore?date=all&q=youcompl...

View on HN

YouCompleteMe used fuzzy finding to create something like IntelliSense.

LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with, and in conjunction with the Debug Adapter Protocol allows things like setting breakpoints in a standardized way.

EDIT: looks like YouCompleteMe did try to use OmniSharp and racer to provide better support for certain languages, but it still is different than a standardized protocol that any language could add support for without needing to be included in a swiss army knife like YCM.

> LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with

That's what YCM did as well. Well, compilers or other intellisense-adjacent tools (like Jedi for Python, which Python's language server also used, or Tern for JS).

YCM includes various non-standardized static analyzers and such, and glues them together to be a swiss army knife. LSP is a standardized API that compilers can target, and that means there is no need for a middleware component that does work.

YouCompleteMe provided an API that abstracted away what compilers/tools were on the backend and gave you information that an editor could use. Just like LSP.

Yea, but LSP gives an API target for the compilers not just for the editors.

I still use YouCompleteMe and even standard ctags because they fill additional functionality that an LSP can't provide. In a big C++ project you'll have several different configurations that can be built, none of which touch all files. In that case the LSP can't give you completions and diagnostics for a file that isn't built, but YCM can often deal with it by compiling with include paths similar to surrounding files. So this way I can safely edit and browse files of other configurations. Similarly if you're building for different OSes, you have chunks of code behind #ifdef linux/WIN32/osx, so they just never get compiled and the only thing that can index e.g. structs defined within those ifdefs is good old dumb ctags. I strongly feel that the union of these different tools that operate at different levels of integration with the build system results in a much more comprehensive solution for real-world systems than would be possible with just one of them.

whoops this was supposed to be a reply to https://news.ycombinator.com/item?id=18883088, mods feel free to move it.

Reply on news.ycombinator.com