[FYI] VSCode Client / Server Language Protocol

[mispencer]

Apparently Microsoft and Eclipse are jointly working on a code completion/diagnostic/analytics protocol. Is this something ycmd might be interested in supporting?

Current protocol spec

[Valloric]

Thanks for the heads-up!

Let's see if it takes off first. For YCM/ycmd, it's not solving any problems we have so I see no benefit to implementing it. That may change in the future of course, and at that time we can reopen this.

[romix]

Apparently, YCMD is probably a single tool that provides Clang-based auto-completion using a server for it. If it would implement this protocol, a number of editors could immediately benefit from it. E.g. Eclipse CDT (C/C++ Development Tooling) could make use of this feature, which is more powerful and usable than their built-in auto-completion.

[romix]

Visual Studio Code and Atom would be two other interesting editors, who could make use of this feature. Combined with Eclipse, it makes a pretty interesting set of editors with a pretty broad user base.

I don't see any reason to ignore this possibility of extending YCMD users base, if adding a support for the Language Server Protocol would be probably almost as easy as providing a new skin for the existing YCMD protocol.

[sztomi]

@Valloric It does seem like Language Server Protocol took off: https://langserver.org/

[bstaletic]

@sztomi Take a look at the PRs. There is one that implements jdt.ls support.

[sztomi]

@bstaletic You misunderstand. That PR adds a Language Server Client to YCMD, while this issue we are commenting on proposes that YCMD implements the Language Server Protocol so that all editors that support LSP can be YCMD clients.

[puremourning]

how many editors are there that would benefit from this ? pretty sure someone already wrapped ycmd with a LS clone for vscode.

anyway, what Val said originally stands:

it's not solving any problems we have so I see no benefit to implementing it.

Indeed implementing it requires a significant change of ethos for the API and that would actually make client implementations more difficult. In particular, the Vim client which is the one we maintain.

[sztomi]

https://langserver.org/ lists editor support.

already wrapped ycmd with a LS clone for vscode

Most ycmd clients apart from the official vim client are very bad quality, littered with problems and most often abandoned (I tried the ones for Sublime Text, vscode and Atom). This is the issue that supporting LSP solves: editors invest in supporting LSP in general, so any server providing LS will be well-supported.

[puremourning]

My experience of implementing a LSP client is that each client requires intimate knowledge of the server it speaks to. I have tried 5 different servers, and each requires customisation based on its own random behaviours, so I'm honestly not sure that this is entirely viable at this stage.

I'm also not convinced there is appetite within the ycmd maintainers to maintain 2 completely different interfaces. At least, there's no such appetite from myself. LSP assumes a lot of features of editors that many ycmd clients don't currently have, and are not easy to build.

FWIW I accept that this is potentially biassed opinion as the maintainers predominantly themselves use Vim which is itself very limited in certain ways vs. other editors. But ultimately, we're the ones that have to build and maintain it :)

[sztomi]

Fair enough.

[bstaletic]

I'm also not convinced there is appetite within the ycmd maintainers to maintain 2 completely different interfaces.

I'm definitely not interested in maintaining two interfaces. It's one or the other and I like our current one better.

[Valloric]

I'm going to chime in here and say that the main voice for whether LSP support ends up in ycmd would be @puremourning. He has spent a ton of time implementing the protocol so that ycmd can talk to it and he also has years of experience with ycmd itself (being a YCM/ycmd maintainer).

So if he says it's not entirely viable right now, IMO that settles it (at least for now; this can change in the future).