Update README.md

[ryanbas21]

Use initialization options instead of settings in json for coc

It took me way longer than i'm willing to admit to finding this setting. I was able to get builds on save by using this and not need a watcher when running parcel. It did not work when in the settings.purescript keys, so I think this may be a nice to add to people don't have to go digging.

[nwolverson]

Hmmm, that doesn't look right according to the docs to me, these settings should be settings not initializationOptions https://microsoft.github.io/language-server-protocol/specification#initialize

[andys8]

Three months ago, initializeSettings didn't work for me, but settings did. See #55 (comment)

I gave it another try, and compared both approaches to apply configuration.

Example: pursExe

Expectation: No compilation errors, because the path to purs is wrong.

initializationOptions

Shows a compile error, but shouldn't. Setting has no effect.

      "initializationOptions": {
          "pursExe": "purs-wrong"
      }

settings

Nothing happens (expected).

      "settings": {
        "purescript": {
          "pursExe": "purs-wrong"
        }
      }

Example: autocompleteLimit

Expectation: Autocompletion items should be limited to exactly 2.

initializationOptions

10(+) items listed here, but should be 2. Setting has no effect.

      "initializationOptions": {
        "autocompleteLimit": 2
      }

settings

2 items provided by the language server (third one is from Vim, because no indicator on the right).

      "settings": {
        "purescript": {
          "autocompleteLimit": 2
        }
      }

Open Questions

I noticed @oblitum removed the settings from the CoC Wiki with the comment "Remove unecessary broken configuration". (Update: From what I see can publicly, I would guess @oblitum is a CoC contributor, but not a purescript user, though. The change might be based on assumptions. Not correct). And also this PR speaks for people having different experiences. Maybe we can find out more, here, and then extend the documentation.

• Is it different depending on which option one is testing?
• Are both ways of configuration working in some cases?
• Is it depending on CoC version or another external factor?

System

vim version: VIM - Vi IMproved 8.2 8021989
node version: v14.9.0
coc.nvim version: 0.0.80-7642d233d6
purescript-language-server@0.14.4

[oblitum]

Update: From what I see can publicly, I would guess @oblitum is a CoC contributor, but not a purescript user, though. The change might be based on assumptions

• No instantaneous diagnostics feedback? #53
• https://github.com/neoclide/coc.nvim/wiki/Language-servers/_compare/a84dc40e0eeef5ca1af94fdc26cc25a848eedd4d

I removed with a reason, just don't recall it anymore. Besides that, the Wiki there should present basic working configurations as a start, not opinionated settings. Users should look for server documentation on that. This reduces the chance of the Wiki to be eventually broken.

[nwolverson]

I can't give specifically coc support, but I can say that this language server has always used the standard language server configuration/settings API in one form or another:

workspace/didChangeConfiguration
workspace/configuration

That's what's used in vscode for example to map the standard settings to a language server.

Almost nothing is via initializationOptions, some servers may use this for some configuration that must be "static" at init, feature flags or what have you, but we don't do that (just 1 vscode specific thing that can probably go at some point).

For reference, if there is a problem the appropriate information would be logs from the language server <> editor communication (either the window/logMessage messages, or the full communication as convenient/appropriate) - usually at startup relevant information will come out, eg when starting the purs server is the path correct

[nwolverson]

With reference to the wiki change - it looks like those settings now have been trimmed down a bit in general, I think I recall seeing some settings on individual servers (though for some reason python's is massive...). I'd view the settings section more as an indication where settings are located/structured rather than a specific suggested setting, but I'd agree that is unlikely to be clear.

Further info can always be on this README