Server-specific options are not used for workspace/configuration response

[smackesey]

Describe the bug

For language servers configured without a CoC extension (i.e. those under the "languageserver" field in the settings), the workspace/configuration request is not correctly handled. When CoC receives this request, it should build the response from the content of `"languageserver"/""/"settings". Instead CoC looks at the top level of the configuration for the keys.

This is a problem for some language servers that do not initialize all settings with workspace/didChangeConfiguration request on startup (which is populated by the settings). For example, some settings in Microsoft's pylance appear to be set only via the response to the server's workspace/configuration request:

[Trace - 3:17:08 PM] Received request 'workspace/configuration - (3)'.
Params: {
    "items": [
        {
            "scopeUri": "file:///Users/smackesey/stm/conf/ext/vim",
            "section": "python"
        }
    ]
}

In order to return the appropriate response, coc-settings.json must have have python.* settings defined at the top level, which CoC complains about because it doesn't know about these settings.

Reproduce the bug

This should be reproducible with any language server that sends a workspace/configuration request. Pylance is an example. Configure the language server with trace.server verbose and check the Coc log. You will see that the response to workspace/configuration is built from the top level and not from the language server settings.

[chemzqm]

It's expected, you need coc extension

[smackesey]

Would you accept a PR changing this behavior? The current behavior makes no sense. At the very least, it should be documented.

[chemzqm]

It should be bug of your language server, you can provide verbose output

[smackesey]

This can't be a bug of the language server, since the server has no control over how CoC builds the response to the workspace/configuration request sent by the server. The problem is that CoC builds the response from the top level settings in coc-settings.json instead of using the settings defined for the specific language server.

[chemzqm]

Fixed, configuration for user defined language server read configuration from settings field only.

[smackesey]

Hmm... actually this commit does not seem to have fixed the problem. What happens now is that settings aren't read from either the top level or the server specific settings. I see this in the log for pylance:

[Trace - 9:12:48 AM] Received request 'workspace/configuration - (4)'.
Params: {
    "items": [
        {
            "scopeUri": "file:///Users/smackesey/stm/conf/ext/vim",
            "section": "python.analysis"
        }
    ]
}


[Trace - 9:12:48 AM] Sending response 'workspace/configuration - (4)'. Processing request took 1ms
Result: [
    null
]

Even though I have python.analysis.* settings like this:

...
"languageserver": {
  "pylance": {
     ...
    "settings": {
      ...
      "python.analysis.typeCheckingMode": "basic",
      ...
    }
  }
},
...
"python.analysis.typeCheckingMode": "basic",
...

[chemzqm]

Avoid . in keys of settings