Language-server-protocol: What about language-configuration (client side) specification?

[angelozerr]

I know it's out of topic of this github repository but I don't know where I could post my question. But it should be very cool if we could have a specification for language configuration outside vscode https://code.visualstudio.com/docs/extensionAPI/extension-points#_contributeslanguages

Indeed, this language-configuration.json can be used outside vscode. We have started to implement language configuration for Eclipse in TM4E project (see https://github.com/eclipse/tm4e/wiki/LanguageConfiguration)

Goal of Language Server is to share work about completion, folding, hover, etc for any editor, but other features like comments, brackets which is not part in LSP is managed with language-configuration.

I tell me what you think about this idea of language configuration specification that we could have for instance in https://microsoft.github.io/language-configuration/specification like we have for LSP https://microsoft.github.io/language-server-protocol/specification

[egamma]

@angelozerr this is a good observation.

When we looked into how to provide smart editing (matching brackets, auto indent, comment/uncomment) we have found that all editors already different ways for defining this (e.g. https://github.com/textmate/c.tmbundle). For this reason, we did not attempt to introduce a new specification, but implement a custom solution for VS Code as well. This is different from LSP where there was a gap and therefore the chances where high that this gets widely adopted. Also where do you stop? Does the language configuration include snippets and themes as well?

Adding a specification of the language config options would be doable, but given that most editors already cover this, this hasn´t become a priority yet.

[mickaelistria]

how would adopt such a specification (given that all editors have a way to do so)
...
Adding such a specificaiton would make sense, but given that most editors already cover this, this hasn´t become a priority for us, yet.

I don't think this has to be specified at the moment. Just like TextMate grammar files can be used by several editors/IDEs while they're not specified.
However, it could be worth mentioning somewhere in the LSP site that these format and other ones exist to complete the UX. Or to just put a piece of your answer as a comment on the spec so tools developers looking for a more share-able way to implement/support syntax highlighting, bracket matching, auto-edit and so on would be driven to TextMate grammars and language-configuration.json files, resulting in higher reusability of their work.

[egamma]

Adding this in the documentation makes sense to me. Assigning the issue to me.

[angelozerr]

Adding this in the documentation makes sense to me. Assigning the issue to me.

Thanks @egamma for that. I love language configuration because it is very simply and it hosts in the same place the missing features of language server.

Thanks @mickaelistria for clarify things.

[dbaeumer]

Ping @egamma

[dbaeumer]

I will close this at out of scope. I do see the desire but it doesn't fall into LSP specification and no one really picked up on working on it.