Why addToDictionary, disableRules, hideFalsePositives are supposed to be handled by the Client?

[devzbysiu]

Hi,

First, sorry if there is an obvious answer, I'm not deep into LSP, so it's not obvious to me.

I started using ltex-ls and I observed that the client I'm using (https://helix-editor.com/) does not support actions like addToDictionary, disableRules, hideFalsePositives.

Then I started to dig deeper and found #96 and docs, which suggests that those actions should be implemented by the client.

Then I started to investigate how this could be done in helix, but I realized that I would have to handle _ltex.addToDictionary etc. as a special case specific for this LSP. This is fine if the client supports plugins like sublime text or vscode, so we could have a plugin which is specific for this language server, so it handles this language server's methods.

However, for clients which does not support plugins, it may not be the best idea to handle any methods specific to the language server on the client side, because users of this client would be paying the cost of the additional code, even if they don't use that language server.
It's not a problem when there is a plugin system, because users install plugins they want, and they won't pay the cost of plugins they don't install.

There is an info in README.md:

Some commands are handled by LTEX LS , while others must be handled by the language client. This is in contrast to the LSP specification, which recommends that the server handles all commands. However, handling of some commands by the client is necessary as these commands change the client configuration, which the LSP does not allow server-side.

As far as I understand, this means that dictionary, disabled rules and false positives are considered client configuration. Does it mean that each client is supposed to have its own dictionary etc.?

I can imagine the case that I'm using ltext-ls for helix, vim, emacs etc. and I would expect that when I'm adding a word to a dictionary in helix, then this word won't be highlighted later when I'm using vim or emacs. Of course, I could point every client to the same, dictionary and this would solve such a case, but then this dictionary won't be considered a client configuration, because it would be global.

I glanced over ltex-ls code, and it looks like it would be possible to pass a path to a dictionary file to the server via client's configuration, and then handle _ltex.addToDictionary etc. on the server side. This way we can still use different dictionaries etc. per client or use global one - depending on the needs, and the client doesn't need to have server-specific code.

The question is: What is the reason to handle _ltex.addToDictionary, _ltex.disableRules, _ltex.hideFalsePositives on the client side?

[valentjn]

Does #133 answer your question?

I'm starting to have second thoughts on this. Many clients are struggling with this. Maybe we should move the workspace-specific configuration back to the server, require that a workspace must be open in order for them to be applied, and save them in something like <WORKSPACE_FOLDER>/.ltex/. It wouldn't be an easy change, though.

[devzbysiu]

Hi @valentjn , yes, #133 answers my question perfectly! Thank you for the answer. Closing this question

[rcorre]

I'm using helix as well, and I found this question trying to figure out why the "Add to dictionary" setting doesn't work. I'm not following the connection with #133, and both issues are closed. It seems like we want the client configuration to contain a dictionary path (rather than a list of words), so the server can handle adding words to it. Is that still doable?

[ferntheplant]

Another Helix user hopping onto this thread. It looks like if ltex-ls were to receive a workspace/didChangeConfiguration notification from a client editor with an up to date dictionary then it actually does nothing with the new config that was sent over (source - correct me if I'm misunderstanding the code).

If it were to re-run diagnostics with the new config then helix users could use a script to append text selections to their local config dictionary (see my comment here) and then the Helix LSP client can simply send the workspace/didChangeConfiguration with this updated config (ignoring some Helix specific config reloading stuff for brevity) and get instant dictionary updates.

I'm not familiar with Kotlin but willing to give it a go at implementing the configuration change update logic if this sounds reasonable to you @valentjn