[Feature request] expose `initializationOptions` for LSP

[matan-h]

Many LSPs, such as ty (config docs) uses the LSP option of initializationOptions to determine language-specific settings, like adding auto-import suggestions

Use case: I am building a super minimal python editor with ty LSP, and it would be nice if I could use

LspStdioConfig.start(
      executable: "ty",
      ....
      initializationOptions:{"completion": {"autoImport": false}}
)

Looking at the code

code_forge/lib/LSP/lsp.dart

Lines 103 to 105 in e653725

	'initializationOptions': {
	'highlight': {'enabled': true},
	},

It seem to be already sending this, just without user ability to add more options.

Thank you for the awesome project,
matan-h

[heckmon]

Thank you for using code_forge. I had a plan to add this feature like the LspClientCapabilities capabilities in the LspConfig class, but each language server has it's own initialization options, so I kept it untouched.
However I'll add a parameter called Map<String, dynamic> initializationOptionsin the LspConfig class on next release as you requested.

Currently I'm busy with my college exams. So the next release might be delayed.

Also, if you're building a web app, use code_forge_web.

[matan-h]

From small research, what I did want was to change the response to workspace/configuration. it turns out if I understand correctly (feel free to correct, I dont really know about this ):

initializationOptions defined in the spec as User provided initialization options. so the LSP load them, and use them to startup (e.g. location of python.exe) . but when we send workspaceFolders, they are not using this as a default. instead, they reset the config and waiting for the workspace specific configuration.

When I patch the code to do initializationOptions:{"completion": {"autoImport": false}} it ignore those startup settings in favor of reset them for workspace

So I think if CF will support workspace/configuration, it might help some LSPs to work correctly.

[heckmon]

Ok I'll look into that. I went through the ty docs, it says you can configure these stuffs using the ty.toml file. It can be placed in either the workspace directory or any custom location and specify it's path using TY_CONFIG_FILE environment variable or the --config-file flag.

Or simply, you can use the --config or -c flag to pass the configuration directly to the executable without having any file.
https://docs.astral.sh/ty/reference/cli/#ty-check

However I'll add a parameter to set the workspace/configuration.

[matan-h]

you can configure these stuffs using the ty.toml

That's true, however, the LSP settings aren't there. ty.toml intended as a way for every workspace to configure the type checker, therefore it doesn't expose editor settings like auto-import suggestions , show types, etc.

[matan-h]

Following debug in astral-sh/ty#2993 (comment) , it turn out I dont actually need workspace/configuration, it should behave the same with either initializationOptions or workspace/configuration (what I said earlier about workspace/configuration begin used at the start was incorrect, should not be the case for valid servers)

The root of the initializationOptions bug was me :) specifying a root URI that does not include the target file. it should be valid to use initializationOptions

[heckmon]

So, is it working properly?
However I'll add an options for workspace/configuration because other editors like VScode, zed, neovim, etc has this feature.

[matan-h]

yes, it still needs one of initializationOptions or workspace/configuration, to be able to specify options