Allow language server options to be provided in a file during startup.

[davidfestal]

Some Language server clients (such a Eclipse Che), don't allow sending configuration options through the JsonRPC protocol. In such a case, it would be helpful to be able to provide, as a language server command line parameter, the name of a file that would be searched for in the project .ceylon subdirectory and that would contain the LS configuration.
Something like: --override-lsp-config=<file>
This would instruct the LS, when starting on a project, to read the configuration from this file instead of waiting for the configuration JsonRpc message.

[jvasileff]

@davidfestal do you know off-hand what the best way to parse Ceylon's config file format is?

[jvasileff]

I suppose there are three relevant settings.

Should the prefix be lsp, as in lsp.backend, lsp.generateOutput, and lsp.serverLogPriority?

                "ceylon.backend": {
                    "type": "string",
                    "default": "dart",
                    "description": "The compiler backend to use. Currently, the Dart and JavaScript backends are supported. Visual Studio Code must be restarted after changing to this setting.",
                    "enum": [
                        "dart", "js"
                    ]
                },
                "ceylon.generateOutput": {
                    "type": "boolean",
                    "default": false,
                    "description": "Write compiled binaries to the output repository (Dart backend only). Note that output is produced regardless of whether or not the source files have been saved."
                },  
                "ceylon.serverLogPriority": {
                    "type": "string",
                    "default": "disabled",
                    "description": "The logging level for the language server. For levels other than 'disabled', a log file will be created for each instance of the extension. Log files will be created in the '/tmp' directory if it exists, or the system default temporary directory otherwise.",
                    "enum": [
                        "trace", "debug", "info", "warn", "error", "fatal", "disabled"
                    ]
                }

[davidfestal]

In fact I'm not even sure that it should follow the Ceylon's config format. It could simply contain the JSON that you would otherwise receive through RPC.
And not sure, as well, that it would be necessary to create it in the .ceylon directory.
The argument could be the relative path from the root of the project

[jvasileff]

This file is to be hand edited by users, no? Is there a good reason to break from Ceylon convention?

[davidfestal]

then I think that lsp is a good prefix

[jvasileff]

@davidfestal this is very specific to Che, so any particular reason for the generic prefix? My concern is that it would cause confusion for VSCode users, depending on the name of the config file, which brings me to...

Can we just use the normal Ceylon configuration mechanism? That's a) something the code already looks at, and b) it would allow users to put global configs in ~/.ceylon/config. Is there a reason that separate files were used for Eclipse (ide-config) that would be relevant here?

With these points, an idea is to have the cli option --config-prefix, and the Che client would set it to che. The VSCode client wouldn't use this option.

WDYT?

p.s. another argument against lsp is that users don't care about how the IDE works. The fact that it uses a language server is an implementation detail. What they are aware of is that they are using Che or VSCode or whatever.

[jvasileff]

With any luck at all, the latest push will support .ceylon/config options:

[che]
backend=js # or dart
generateOutput=true # anything else is false
serverLogPriority=info # or trace, debug, info, warn, error, fatal, disabled

if the CLI arguments --config-prefix che are provided.

I'll leave this open for now in case this doesn't meet @davidfestal's needs, and also because I only did very basic testing.