Add multiple language server association with syntax elements

[indelog]

Improve multi-language server support by enabling the selection of the appropriate LSP based on syntax stack elements using a new configuration option for the LSP: syntaxAssociatedLSP, which accepts a list of syntax names obtainable through:

synstack(line, col)->map((_, v) => v->synIDattr('name'))

This enhancement allows by example, the simultaneous use of a PHP and HTML LSP in a PHP file when an LSP function is triggered. If the syntax stack contains an htmlTag pattern, the HTML LSP is called; otherwise, the PHP LSP is utilized. Furthermore, this improvement supports cases like embedding GraphQL blocks in TypeScript files.

Example usages include situations like the following configurations:

    call LspAddServer([
                \{
                \    'name': 'phpactor',
                \    'filetype': ['php'],
                \    'path': expand('~') . '/.local/bin/phpactor',
                \    'args': ['language-server'],
                \},
                \{
                \    'name': 'htmlls',
                \    'filetype': ['html', 'php'],
                \    'path': l:lib_path . 'node_modules/.bin/html-languageserver',
                \    'args': ['--stdio'],
                \    'initializationOptions': {'embeddedLanguages': {'css': v:true, 'javascript': v:true}},
                \    'syntaxAssociatedLSP': ['htmlTag', 'htmlError'],
                \    'runUnlessSearch': [
                \      'angular.json',
                \    ],
                \},
                \{
                \    'name': 'typescript-language-server',
                \    'filetype': ['typescript', 'javascript'],
                \    'path': l:lib_path . '/node_modules/.bin/typescript-language-server',
                \    'args': ['--stdio'],
                \},
                \{
                \    'name': 'graphql-language-server',
                \    'filetype': ['typescript', 'javascript', 'graphql'],
                \    'path': l:lib_path . '/node_modules/.bin/graphql-lsp',
                \    'args': ['server', '-m', 'stream'],
                \    'initializationOptions': {'diagnostics': 'true'},
                \    'syntaxAssociatedLSP': ['graphqlTemplateString'],
                \},
                \])

While acknowledging that this approach is relatively straightforward, I believe it remains effective for conventional use cases as long as the language server is designed to operate within the context of the current file.

[Shane-XB-Qian]

seems unnecessary?

[indelog]

This is a minor fix. Using the apt command in scripts is discouraged, and it is recommended to use apt-get instead. According to the apt manual:

The apt(8) commandline is designed as an end-user tool and its behavior might change between versions. Although it aims to maintain backward compatibility, this is not guaranteed if a modification appears advantageous for interactive use.

That's why a warning message is issued when apt is employed in a script.

However, this fix can be safely ignored; nevertheless, there isn't a reason to ignore it.

[Shane-XB-Qian]

it has no pipeline here, maybe it's ok.

[Shane-XB-Qian]

redundant blank line.

[Shane-XB-Qian]

i saw your commit, as i knew yegappan would not squash the commits when merging, maybe you need to squash it later, otherwise you would see the commits history (and tho the contribute count too) a little redundant too, 😄
// just an irrelevant comment, and it's on yegappan.

[Shane-XB-Qian]

how reliable of this? and need to dyn change/config the syntax value?

[indelog]

I don't foresee a situation where we need to dynamically change the syntax. Can you provide an example to help me understand what you mean?

[Shane-XB-Qian]

i meant the syntax value was not reliable, or dynamic, perhaps if there was a way to auto detect the syntax value (which it belonging) would be great, otherwise e.g markdown file, there perhaps embedded some unconcern code block.

[Shane-XB-Qian]

perhaps just using markdown lsp? vs/but not need to make up a dummy lsp.

[indelog]

I merely wanted a simple LSP setup for a very basic use case, keeping the unit tests equally simple.

The dummy LSP can be configured to return varying responses to hover requests, thus serving as a convenient way to mimic different LSPs using just one. Without this approach, you would have had to rely on two distinct LSP implementations—for example, starting with a PHP file, configuring both phpactor and html-languageserver, and checking whether the correct LSP responds upon querying an htmlTag. I find this complicates the tests unnecessarily.

Should implementing a fake LSP for simple mocking in tests prove problematic, replacing it with actual LSP instances wouldn't be an issue.

Do note that the dummy LSP could potentially be expanded for conducting additional tests. This idea serves as a suggestion rather than a requirement.

[Shane-XB-Qian]

you can use a markdown file which embedded clang/golang etc code block to test, which those had been config into test of this codebase, if so, the code base would be clean and easy.

[indelog]

I modified the unit tests according to recommendations, removing the dummy LSP. Although these tests aren't as extensive, they ensure the right LSP is invoked, which should be enough. Testing real LSP execution isn't feasible as clangd doesn't understand Markdown, and ultimately, testing real LSP execution turns out to be unnecessary because selecting the appropriate LSP suggests that everything else will most likely fall into place.

[Shane-XB-Qian]

thanks, seems a good try,
but not sure how reliable was it, and need to dyn change/config the syntax value? seems a little not easy to use.

BTW: truly there now still some problem so far no good answer, e.g:

1. like this one, how to easily handle embedded code.
2. some lsp handle for same ft, e.g yaml and ansible was both to 'yml' ft.

[indelog]

With this proposal, I do not claim to fully address the complex challenge of multi-LSP, but rather aim to enhance existing options with a simple solution built upon Vim's inherent syntax identification capabilities.

This works smoothly in cases where the LSP is designed to operate within the given context. As demonstrated, the proposed solution excels in cases like PHP files with embedded HTML or TypeScript files featuring GraphQL templates. By maintaining the primary LSP as the default and placing it first in the LSP list, complementary LSPs are included only when encountered within a specific syntax group. Notably, the script processes the complete syntax stack of the current word, starting from the highest level.

Admittedly, cases similar to the YAML Ansible scenario cannot be resolved solely through the suggested approach, as decisions concerning the appropriate LSP cannot depend exclusively on file syntax. In such circumstances, tradeoffs must be made, leaning on other configuration options like runIfSearch or features. For instance, choosing the Angular LSP over the HTML LSP requires the following configuration:

    call LspAddServer([
                \{
                \    'name': 'angular',
                \    'filetype': ['html'],
                \    'path': g:lib_path . 'node_modules/.bin/ngserver',
                \    'args': [
                \      '--stdio',
                \      '--tsProbeLocations',
                \      g:lib_path . 'node_modules/typescript/lib/',
                \      '--ngProbeLocations',
                \      g:lib_path . 'node_modules/@angular/language-server/bin/',
                \    ],
                \    'initializationOptions': {'diagnostics': 'true'},
                \    'runIfSearch' : [
                \      'angular.json',
                \    ],
                \},
                \{
                \    'name': 'htmlls',
                \    'filetype': ['html', 'php'],
                \    'path': g:lib_path . 'node_modules/.bin/html-languageserver',
                \    'args': ['--stdio'],
                \    'initializationOptions': {'embeddedLanguages': {'css': v:true, 'javascript': v:true}},
                \    'syntaxAssociatedLSP': ['htmlTag', 'htmlError'],
                \    'runUnlessSearch': [
                \      'angular.json',
                \    ],
                \},
                \])

[Shane-XB-Qian]

With this proposal, I do not claim to fully address the complex challenge of multi-LSP, but rather aim to enhance existing options with a simple solution built upon Vim's inherent syntax identification capabilities.

i know, so i am just discussing, not against it, but just the detection on syntax val seems manually seems was not reliable, or IF it would be auto then would be great.

as for 'ansible', there was no fixed file like 'angular.json', but shared yaml lsp with same ft, that's another knew problem.

[Shane-XB-Qian]

if so, no such dir or not req now.

[indelog]

Manually configuring the syntax may seem non-optimal. But this can have certain advantages, notably allowing the user to adapt their configuration as they wish without having to worry about whether the LPS plugin supports the scenario or not.

On the other hand, this can in fact sometimes be tricky. I actually got trapped with the new unit tests because on my machine a C language block is recognized with the syntax name markdownHighlight_c whereas with the version of vim used by the CI is markdownHighlightc. This is why I added the small utility command LspUtilGetCurrentSynStack to help find which syntax name used for syntaxAssociatedLSP.

As there is no standard regarding the name of syntax identifiers and each syntax description has its own terminology, I do not see how to automate the process of identifying syntax names depending on the context. Any idea suggested?

[Shane-XB-Qian]

Any idea suggested?

i like your 'try', but so far no good answer, wish there some more convenience or reliable way.

[jclsn]

Would this fix #521 ?