The initialization options parsing can't recognize nested json, which some language servers accept in their settings.

[akriegman]

For rust-analyzer, I wanted to pass the initialization options {"checkOnSave":{"command":"check"}}, but the plugin parsed that as {"checkOnSave":{"command":"check"}. Currently the plugin uses a regex to split the option string, and I don't see any way to split the string using a regex and allowing for nested json. We could start counting brackets, but I feel like the real solution to this problem is to split the lsp.server setting into separate settings for each language.

I think that we can already do this to a certain extent right now without even changing the plugin, i.e.

{
  "ft:rust": {
    "lsp.server": "rust=rust-analyzer"
  }
  ...
}

but we would still have to fix the above mentioned bug. IMO we should overhaul the settings format while we're at it, so that people can specify settings like this:

{
  "ft:rust": {
    "lsp.server": "rust-analyzer",
    "lsp.initOptions": {
      "checkOnSave": {
        "command": "check"
      }
    }
  }
}

Or we could have lsp.initOptions be a string, if micro doesn't allow for object valued options. This would be backwards incompatible, but I feel like this is a change worth making at some point, because having one long option is kinda a nightmare. We could also do this in a backwards compatible way by branching on whether there's an = in lsp.server. Anyway, what are people's thoughts on this?

[AndCake]

It would look a lot cleaner with the file type specific options, I agree, even if it might have to be in one line rather than a nice object. I originally had it as an object in the settings but this didn't work based on micro's API (I believe, but will have to double-check, that it only accepts strings as values). To fix the parsing of the initialization options: we have a built-in JSON parser in the main.lua to allow for parsing messages coming from the language servers. So we would be able to properly parse it if it were a JSON.

[akriegman]

Cool, so there's a lot of options for how we can fix this bug, and for how we could change the settings structure. What do you think we should do? I can put together a pull request. Personally, i would go for what i outlined above, with lsp.initOptions being a string and lsp.server accepting either a list or a single command, for backwards compatibility

[AndCake]

Yes the LSP.initOptions being a string is good. And adding the option to read the lsp.server settings file type specific would be a good way to go and not require an additional implementation to make it backwards compatible. If you could put together a PR for this, that would be great!

[AndCake]

@akriegman : I researched and tested option parsing in micro a bit more (including the internals and non-documented methods) but it seems there is no means for a plugin to access such file-type specific settings. From what I saw, it's not possible for a plugin to register any such options. Retrieving it is impossible too. So it seems we will have to stick with the method we have right now.