(I'm a vim user but I'll accept a VS Code answer since that's basically "state of the art" when it comes to LSP and where most others get their inspiration from.)
(I'm a vim user but I'll accept a VS Code answer since that's basically "state of the art" when it comes to LSP and where most others get their inspiration from.)
This seems to have been a design decision from the very start, but I have a hard time understanding why. It seems like a conceptual mistake to me. It also eats up system resources like crazy, but that's a lost cause anyway. Instead of harnessing the capabilities of existing implementations, every "wrapper" kind of language needs to build its own solution, which leads to these solutions often not being great. For example, said HTML/JS solution has issues with external dependencies [3]. Or, I've been trying to enable support for CoffeeScript or Elm inside Vue Single File Component files, but I couldn't so far, even though I'm the author of the CoffeeScript extension. [4][5]
Any source file always has exactly one language type assigned to it (possibly auto-detected), so no, dynamically "switching" is not possible without manually changing it for the entire file. For things like SQL inside PHP, Jetbrains products really are superior.
[1] https://code.visualstudio.com/api/language-extensions/embedd... [2] https://github.com/microsoft/vscode/blob/7fd6f1b1d46bd2223a9... [3] https://github.com/microsoft/vscode/issues/26338 [4] https://github.com/vuejs/language-tools/issues/3200 [5] https://github.com/vuejs/vetur/issues/1184
This should be configured by the user, idk if a default implementation could work correctly in all cases.
-- Initialization of Neovim's LSP client local nvim_lsp = require('lspconfig')
-- Setup for the Ruby LSP nvim_lsp.solargraph.setup {}
-- Setup for an SQL LSP (assuming one exists with the name 'sql_lsp' in this example) nvim_lsp.sql_lsp.setup {}
Less sure about "minor" dsl-like support, like online css/html/js in php etc? (Or SQL strings in c# etc).