-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a config variable to store configuration changes #55
Conversation
I have a setup like this for the contextive language server with custom settings for the contextive path: lspconfig.contextive.setup {
settings = {
contextive = {
path = vim.loop.cwd() .. "/.contextive.yml"
}
},
on_init = function(client)
if next(client.config.settings) then
client.notify('workspace/configuration', { settings = client.config.settings })
client.notify('workspace/didChangeConfiguration', { settings = client.config.settings })
end
end
} The additional client.notify is just to make sure that the notification is sent (This happens automatically on neovim 0.8 onwards). The above configuration does not work with the current contextive language server, but with the changes in the PR this is possible. I'm not sure why this happens and I'm also eager to hear your thoughts on this implementation. |
It's quite puzzling to me as to why this would work: In the
One possibility is that the Omnisharp library will not even make the request if the client has not advertised the configuration capability. I would be interested to see what capabilities the client is advertising. So something that would help is if you can find a way to enable protocol-level logging of the LSP messages. I've found that a trace of the LSP messages sent back and forth usually sheds a lot of light on what's going on with these things - including the initialize method which contains the advertised capabilities. Also odd is that your setting includes:
But Further ThoughtsInterestingly, the way the config is making it through with this PR is that you are capturing the value provided in the However if you think about it, when we get didChangeNotification, we are triggering a reload of the definitions file. We currently pass in a delegate that calls back to the getConfig method - but if we have the actual value, we could just pass in the value and eliminate the delegate (and mutable) altogether. I think the reason I didn't do that initially is that an older version of the Omnisharp library didn't make the config settings available properly in the notification, so I had no choice but to use the I'll do some testing because if neovim and vscode and omnisharp now all properly work together to provide the value in the didchangeconfiguration notification, then the whole structure can be much simpler - we can just pass the new config value directly to the definitions reloader! This is a pretty major change, but if it is possible, would be worth it - I should have a chance to look into it in the next day or so. |
I can print out the capabilities and configuration from the neovim directly. This is the workspace configuration: workspace = {
applyEdit = true,
configuration = true,
didChangeWatchedFiles = <table 19>,
semanticTokens = <table 20>,
symbol = <table 21>,
workspaceEdit = <table 22>,
workspaceFolders = true
} and these are the capabilities: capabilities = {
textDocument = {
callHierarchy = <table 1>,
codeAction = <table 2>,
completion = {
completionItem = {
commitCharactersSupport = true,
deprecatedSupport = true,
documentationFormat = <table 3>,
insertReplaceSupport = true,
insertTextModeSupport = <26>{
valueSet = { 1, 2 }
},
labelDetailsSupport = true,
preselectSupport = true,
resolveSupport = <27>{
properties = { "documentation", "detail", "additionalTextEdits", "sortText", "filterText", "insertText", "textEdit", "insertTextFormat", "insertTextMode" }
},
snippetSupport = true,
tagSupport = <28>{
valueSet = { 1 }
}
},
completionItemKind = <table 4>,
completionList = <29>{
itemDefaults = { "commitCharacters", "editRange", "insertTextFormat", "insertTextMode", "data" }
},
contextSupport = true,
dynamicRegistration = false,
insertTextMode = 1
},
declaration = <table 5>,
definition = <table 6>,
documentHighlight = <table 7>,
documentSymbol = <table 8>,
hover = <table 9>,
implementation = <table 10>,
publishDiagnostics = <table 11>,
references = <table 12>,
rename = <table 13>,
semanticTokens = <table 14>,
signatureHelp = <table 15>,
synchronization = <table 16>,
typeDefinition = <table 17>
}, Maybe you can see something out of place in that data?
I can try to enable the debugging for the lsp protocol and paste the logs here.
Yes that is the 'extra' I mentioned. I am quite puzzled myself too as why this isn't working. Everything seems to be how it should. I have even ventured to omnisharp source code to understand it better. There is a mention in the microsoft language server extension guide however that the language server should support a situation where workspace is not supported. It is hidden in the example code comments: // The global settings, used when the `workspace/configuration` request is not supported by the client.
// Please note that this is not the case when using this server with the client provided in this example
// but could happen with other clients.
const defaultSettings: ExampleSettings = { maxNumberOfProblems: 1000 };
let globalSettings: ExampleSettings = defaultSettings;
// Cache the settings of all open documents
let documentSettings: Map<string, Thenable<ExampleSettings>> = new Map();
connection.onDidChangeConfiguration(change => {
if (hasConfigurationCapability) {
// Reset all cached document settings
documentSettings.clear();
} else {
globalSettings = <ExampleSettings>(
(change.settings.languageServerExample || defaultSettings)
);
}
// Revalidate all open text documents
documents.all().forEach(validateTextDocument);
});
Sounds good to me! Yeah initially I was thinking that probably the right way to change this is actually a bigger overhaul on how the configuration is passed forward. Anyways it feels dirty to have a mutable field. 😅 |
Here is the LSP debug log. There is a custom path, which is provided with the settings from neovim client.
|
Thanks for sharing the log - this is very interesting! I would have expected a I'll review the vscode protocol logs and look for what the differences are prior to that point... probably some subtlety in the |
No problem! Very interesting indeed, and well yeah that explains it on why defining the settings did not work as expected. |
changes When using for example the neovim language server client, the contextive language server does not acquire the proper settings sent by the client in the `OnStarted` handler. However, the settings are passed correctly using the `OnDidChangeConfiguration` handler. This change introduces a scoped variable in the server start function to hold a mutable field for the Contextive path configuration. The configuration variable is initialized with the default path for Contextive definitions introduced in commit 23f9049. If the language configuration does not have a config value, it will use the value from the configuration variable instead. This works the same way as it did previously, but the source is now a parameter of the function.
Hi @erikjuhani, I've had a chance to dig into this a bit further and I think I see why it's hard to diagnose... I think we're dealing with the intersection of two bugs - one in neovim and one in OmniSharp 🤣 OmniSharp BugThe neovim lsp client does not send the I'm working through this to confirm, and once I do I'll raise a bug with the OmniSharp library. NeoVim BugWhile it's technically correct that the nevom lsp client doesn't advertise the capability (because it has no support for monitoring the configuration settings and sending a notification when they are modified), it DOES actually send the SolutionsWhile fixes to upstream of either bug would resolve the situation, there are some potential ways to resolve it from the contextive end:
Given that option 1 is 'end-goal', I'm thinking for now I'll go with option 3 as moving to 1 will involve a pretty big adjustment of the whole config approach, so not much point in doing option 2. Any thoughts? |
Have reported with OmniSharp here: OmniSharp/csharp-language-server-protocol#1101 |
Closing in favour of #58 |
Please check if the PR fulfills these requirements**
Context
When using for example the neovim language server client, the contextive language server does not acquire the proper settings sent by the client in the
OnStarted
handler. However, the settings are passed correctly using theOnDidChangeConfiguration
handler.What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
This change introduces a scoped variable in the server start function to hold a mutable field for the Contextive path configuration. The configuration variable is initialized with the default path for Contextive definitions introduced in commit 23f9049. If the language configuration does not have a config value, it will use the value from the configuration variable instead. This works the same way as it did previously, but the source is now a parameter of the function.
What is the current behavior? (You can also link to an open issue here)
Currently the configuration initialization does not work correctly with nvim (v0.9.2) language client server. I've spent multiple hours trying to understand the cause for this, but alas I'm empty handed here. There must be something that is not right, maybe it could be an OmniSharp issue too.
Other information:
This work is related to #33