Skip to content

Regularise the config for plugins #513

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
alanz opened this issue Oct 18, 2020 · 2 comments · Fixed by #691
Closed

Regularise the config for plugins #513

alanz opened this issue Oct 18, 2020 · 2 comments · Fixed by #691
Assignees
Labels
old_type: meta Planing and organizing other issues status: in discussion Not actionable, because discussion is still ongoing or there's no decision yet type: enhancement New feature or request

Comments

@alanz
Copy link
Collaborator

alanz commented Oct 18, 2020

This is a transfer of haskell/haskell-ide-engine#800 to haskell-language-server.

The essence of it is that we now have an expansion of plugins, and not all people want/like all the features.

Perhaps we should consider a regularisation of the Config structure to have slots per plugin.

At the moment it has an ad-hoc set of setting, intimately tied to the "current" set of plugins.

data Config =
  Config
    { hlintOn                     :: Bool
    , diagnosticsOnChange         :: Bool
    , maxNumberOfProblems         :: Int
    , diagnosticsDebounceDuration :: Int
    , liquidOn                    :: Bool
    , completionSnippetsOn        :: Bool
    , formatOnImportOn            :: Bool
    , formattingProvider          :: T.Text
    } deriving (Show,Eq)

The configuration is the interface to the actual IDEs, and is transferred in JSON format.

One way forward would be to have a slot for plugins in the JSON configuration, which can be indexed by the plugin id, as configured in Main.hs.

This could have a standard structure, to represent enabling/disabling code lenses, etc, as well as a per-plugin custom part, which becomes part of the PluginDescriptor. By doing it this way we get a certain core amount of configuration for free, and allow a composable per-plugin configuration.

This is purely conceptual at this point, I invite anyone to make a concrete PR, if we agree this is a good thing to do.

@alanz alanz added the status: in discussion Not actionable, because discussion is still ongoing or there's no decision yet label Oct 18, 2020
@alanz
Copy link
Collaborator Author

alanz commented Oct 18, 2020

Note: this sorts out #510 #426

@alanz
Copy link
Collaborator Author

alanz commented Dec 20, 2020

Note #164 (comment)

I am starting on an implementation to provide standard enable/disable parts for the individual features, based on a structure something like

-- | A PluginConfig is a generic configuration for a given HLS plugin.  It
-- provides a "big switch" to turn it on or off as a whole, as well as small
-- switches per feature, and a slot for custom config.
-- This provides a regular naming scheme for all plugin config.
data PluginConfig =
    PluginConfig
      { plcGlobalOn :: !Bool
      , plcCodeActionsOn :: !Bool
      , plcCodeLensOn    :: !Bool
      , plcDiagnosticsOn :: !Bool
      , plcHoverOn       :: !Bool
      , plcSymbolsOn     :: !Bool
      , plcFormattingOn  :: !Bool
      , plcCompletionOn  :: !Bool
      , plcRenameOn      :: !Bool
      , plcConfig        :: !A.Object
      }

alanz added a commit to alanz/haskell-language-server that referenced this issue Dec 21, 2020
Make it possible to provide config for a plugin in a regular way, by
using a namespace in the json config space. So we have

```
haskell.plugin.hlint.globalOn
haskell.plugin.importLens.globalOn
```

It is also possible to have finer-grain config, so the individual
parts of a plugin can also be separately enabled/disabled.

Closes haskell#513
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
old_type: meta Planing and organizing other issues status: in discussion Not actionable, because discussion is still ongoing or there's no decision yet type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants