Regularize custom config of plugins #1576
Conversation
|
That really a nice feature. However i had to manually choose the set of configuration options to reduce them as much as possible without lose control. And finally i added only some of them. Having the complete list automatically to cut down it is great! What do you think about another option, named It could be complementary with this one and be done in another pr, of course. |
$ cabal run haskell-language-server -- --generate-default-config
{
"haskell": {
"hlintOn": true,
"formatOnImportOn": true,
"checkParents": "CheckOnSaveAndClose",
"liquidOn": false,
"maxCompletions": 40,
"checkProject": true,
"diagnosticsOnChange": true,
"completionSnippetsOn": true,
"diagnosticsDebounceDuration": 350000,
"formattingProvider": "ormolu",
"plugin": {
"hlint": {
"globalOn": true,
"codeActionsOn": true
},
"moduleName": {
"globalOn": true,
"codeLensOn": true
},
"splice": {
"globalOn": true,
"codeActionsOn": true
},
"pragmas": {
"globalOn": true,
"completionOn": true,
"codeActionsOn": true
},
"eval": {
"globalOn": true,
"codeLensOn": true
},
"ghcide-type-lenses": {
"globalOn": true,
"config": {
"mode": "always"
},
"codeLensOn": true
},
"ghcide-completions": {
"globalOn": true,
"completionOn": true
},
"ghcide-hover-and-symbols": {
"globalOn": true,
"symbolsOn": true,
"hoverOn": true
},
"importLens": {
"globalOn": true,
"codeLensOn": true,
"codeActionsOn": true
},
"ghcide-code-actions": {
"globalOn": true,
"codeActionsOn": true
},
"retrie": {
"globalOn": true,
"codeActionsOn": true
},
"tactic": {
"globalOn": true,
"config": {
"max_use_ctor_actions": 5,
"features": ""
},
"codeActionsOn": true
},
"haddockComments": {
"globalOn": true,
"codeActionsOn": true
},
"class": {
"globalOn": true,
"codeActionsOn": true
}
}
}
} |
I mean, not any editor. This is the vscode editor config, the fact that other editors sometimes support it is a nice bonus. Let's not elevate it to universal status just yet :) Concretely, can we call it |
|
I love the idea here. I haven't dug into the impl, but I'm happy to send a followup wingman PR migrating to the system. |
| import Control.Applicative.Combinators (skipManyTill) | ||
| import Control.Lens hiding (failing, (<.>)) | ||
| import Control.Monad (unless) | ||
| import Control.Lens hiding (failing, (.=), (<.>)) |
There was a problem hiding this comment.
Please don't adjust the formatting of this file
There was a problem hiding this comment.
This was done by the pre-commit hook. I will revert it.
There was a problem hiding this comment.
Thanks. @Ailrun, is there a way we can disable the pre-commit hook for Wingman files?
I am a little bit confused, i thought the json config was inherent to lsp server and no belongs to any concrete editor. So all editors have to use the same json to send and configure the server. |
|
I agree with @jneira. Although other lsp clients may not be able to use it directly whereas they have their own config ways, this json value still represents the superset of configuration acceptable by our server. |
|
At okay, never mind, I misunderstood! :) |
|
Now I think this PR is pretty much ready |
| -- "globalOn": true | ||
| -- } | ||
| geenericDefaultConfig = | ||
| genericDefaultConfig = |
berberman
force-pushed
the
declarative-custom-config
branch
from
922594b to
0bda527
Compare
|
@berberman is there anything I should be doing when I update my properties? The changes don't appear to show up in the VScode settings dialog. |
|
The vscode extension itself should be updated "manually" although the new |
5 participants
With #691, each plugin is able to have a generic config:
{ "pluginName":{ "globalOn":false, "codeActionsOn":false, "codeLensOn":false, "diagnosticsOn":false, "hoverOn":false, "symbolsOn":false, "formattingOn":false, "completionOn":false, "renameOn":false, "config":{ } }where particularly,
configis an arbitrary JSON object representing the dedicated, or the extra custom config, which can be parsed and used by the plugin. However, this is hard to be documented and used from the clinet side -- I don't know much about other lsp clients, but for vscode, we have to write the schema manually, like @jneira did in haskell/vscode-haskell#361, which is kind of cumbersome. So it would be better to automate this process.This PR includes mainly two changes:
Propertiesto let plugin type-safely describe what custom config it use--vscode-extension-schemato ghcide and hls executables, which prints the generated schema for vscode--generate-default-configto ghcide and hls executables, which prints the generated lsp json config with default valuesProperties
In order to make plugins' custom config compatible with vscode, i.e. it's expressible in vscode settings UI, a property is defiend as a direct child of
configJSON object, where the value has five potential types (taken from references of vscode):NumberStringBooleanObjectArrayEnumPropertiesis a set of descriptions of properties used by the plugin. It has a phantom typer :: [*]to make sure the name, or the key of the property is unique, and we can derive the corresponding haskell type of the property once we have its name. Given a property name andProperties, we also can derive a JSON parser of this proeprty, which acts on theconfigobject. Overall,Propertiesis used in two places: vscode schema generation and parser derivation at runtime. Currently type lenses plugin and tactics plugin have their own custom configs, and let's use type lenses plugin as an exmaple:where
propertieshas typeProperties '[ 'PropertyKey "mode" 'TEnum], inferred by GHC. We define a enum property calledmode, which have three valid values and a default value "always". And in plugin handler,we can directly use properties defined in the set with the following function (
ToHsTypemaps property types to corresponding haskell types):It uses the parser derived from the property definition to parse the incoming
Objectfrom lsp monad, returning the default value as fallback if parse error occurs or the resource is unavailable. Plugin'sPropertiesis also wrapped and passed toPluginDescriptor:where
pluginCustomConfigis used only for schema generation, not in normal runtime.Schema generation
Except
diagnosticsOn(because diagnostics emit in shake rules), other generic config values can be captured if the plugin has registered the handler of the lsp capability. Combined withProperties, now we are able to generate the schema: