3 ms·
RE: Other languages this distinction is what you're looking for : https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-se
by iheartmemcache 10y ago
RE: Other languages this distinction is what you're looking for : https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol
Completely separating the tool layer from the language layer. Red Hat, Eclipse, etc have already implemented tons of languages like https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations https://github.com/Microsoft/language-server-protocol/wiki/P...
Haxe, Java, C#, C++ (! probably the most impressive of the list). If you conform to the API you can leverage all of those pre-existing backends.
- antimatter15 10y agoA lot of Carbide's widgets depend on having access to a program's parse tree, which (to the extent of my understanding) a lot of these protocols (Jupyter/MS's Language Server Protocol) don't provide. In order to inspect an expression, we have to be able to take the document, parse it into an abstract syntax tree, determine branches which are expressions, and annotate them so that a code generator can wrap it in some log invocation. It'd be great if it were possible to apply "one simple trick" and support a hundred different languages all at once, but in this case I don't think the existing abstractions really suffice.