Skip to content

Add missing config options in documentation #2203

New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Sep 20, 2021
Merged

Add missing config options in documentation #2203

Changes from 5 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
6963a49
Add missing config options
jneira Sep 17, 2021
6d7e5f3
Section about generic plugin configuration
jneira Sep 17, 2021
4c64727
Add plugin specific config
jneira Sep 17, 2021
022080e
Mark haskell.completionSnippetsOn as deprecated
jneira Sep 17, 2021
2fb2ba9
Merge branch 'master' into doc-config
jneira Sep 17, 2021
8e77cbb
Remove unused diagnosticsDebounceDuration
jneira Sep 17, 2021
8035f3e
Correct typos
jneira Sep 17, 2021
c731c96
Change tone of using hie.yaml suggestion
jneira Sep 17, 2021
477e9d0
Update exclude list precommit hook
jneira Sep 17, 2021
676d0ff
Remove diagnosticsDebounceDuration from source code
jneira Sep 17, 2021
1fd1379
Correct typo
jneira Sep 18, 2021
fbd51d4
Merge branch 'master' into doc-config
mergify[bot] Sep 18, 2021
b06318b
Merge branch 'master' into doc-config
jneira Sep 19, 2021
8563167
Merge branch 'master' into doc-config
mergify[bot] Sep 19, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 39 additions & 7 deletions docs/configuration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,14 +40,46 @@ This option obviously would not make sense for language servers for other langua

Here is a list of the additional settings currently supported by `haskell-language-server`, along with their setting key (you may not need to know this) and default:

- Formatting provider (`haskell.formattingProvider`, default `ormolu`): what formatter to use; one of `floskell`, `ormolu`, `fourmolu`, `stylish-haskell`, or `brittany` (if compiled with the brittany plugin)
- Format on imports (`haskell.formatOnImportOn`, default true): whether to format after adding an import
- Diagnostics on change (`haskell.diagnosticsOnChange`, default true): (currently unused)
- Completion snippets (`haskell.completionSnippetsOn`, default true): whether to support completion snippets
- Liquid Haskell (`haskell.liquidOn`, default false): whether to enable Liquid Haskell support (currently unused until the Liquid Haskell support is functional again)
- Hlint (`haskell.hlintOn`, default true): whether to enable Hlint support
- Formatting provider (`haskell.formattingProvider`, default `ormolu`): what formatter to use; one of `floskell`, `ormolu`, `fourmolu`, `stylish-haskell`, or `brittany` (if compiled with the brittany plugin).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these might be better as tables?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, it will look cleaner

- Format on imports (`haskell.formatOnImportOn`, default true): whether to format after adding an import.
- Diagnostics on change (`haskell.diagnosticsOnChange`, default true): (currently unused).
- Diagnostics debounce duration (`haskell.diagnosticsDebounceDuration`, default 350000 milliseconds).
- Completion snippets (`haskell.completionSnippetsOn`, default true): whether to support completion snippets. *Deprecated* as it is equivalent to `haskell.plugin.ghcide-completions.config.snippetsOn`.
- Liquid Haskell (`haskell.liquidOn`, default false): whether to enable Liquid Haskell support (currently unused until the Liquid Haskell support is functional again, see <https://github.com/haskell/haskell-language-server/issues/367>).
- Hlint (`haskell.hlintOn`, default true): whether to enable Hlint support. *Deprecated* as it is equivalen to `haskell.plugin.hlint.globalOn`
- Max completions (`haskell.maxCompletions`, default 40): maximum number of completions sent to the LSP client.

- Check project (`haskell.checkProject`, default true): whether to typecheck the entire project on load. As it is activated by default could drive to bad perfomance in large projects.
- Check parents (`haskell.checkParents`, default `CheckOnSaveAndClose`): when to typecheck reverse dependencies of a file; one of `NeverCheck`, `CheckOnClose`, `CheckOnSaveAndClose`, or `AlwaysCheck`.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it can affect performance it should be noted how


#### Generic plugin configuration

Plugins have a generic config to control their behaviour. The schema of such config is:

- `haskell.plugin.${pluginName}.globalOn`: usually with default true. Wheter the plugin is enabled at runtime or it is not. That is the option you might use if you want to disable completely a plugin.
- Actual plugin names are: `ghcide-code-actions-fill-holes`, `ghcide-completions`, `ghcide-hover-and-symbols`, `ghcide-type-lenses`, `ghcide-code-actions-type-signatures`, `ghcide-code-actions-bindings`, `ghcide-code-actions-imports-exports`, `eval`, `moduleName`, `pragmas`, `refineImports`, `importLens`, `class`, `tactics` (aka wingman), `hlint`, `haddockComments`, `retrie`, `splice`.
- So to disable the import lens with an explicit list of module definitions you could set `haskell.plugin.importLens.globalOn: false`
- `haskell.plugin.${pluginName}.${lspCapability}On`: usually with default true. Wheter a concrete plugin capability is enabled.
- Capabilities are the different ways a lsp server can interact with the editor. The current available capabilities of the server are: `callHierarchy`, `codeActions`, `codeLens`, `diagnostics`, `hover`, `symbols`, `completion`, `rename`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤯

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a table here too?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like tables!

Also this is a good conceptual explanation, but for our users I don't think it's enough that they can know which options they can actually set - they'd have to know which plugins have which capabilities.

I think the best thing is just a big, dumb, table. Ideally auto-generated!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree, what do you think about merge this as is and improve it in other pr's?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes, definitely!

- Note that usually plugins don't provide all capabilities but some of them or even only one.
- So to disable code changes suggestions from the `hlint` plugin (but no diagnostics) you could set `haskell.plugin.hlint.codeActionsOn: false`
- Plugin specific configuration:
- `tactic` (aka wingman):
- `haskell.plugin.tactics.config.auto_gas`, default 4: The depth of the search tree when performing "Attempt to fill hole". Bigger values will be able to derive more solutions, but will take exponentially more time.
- `haskell.plugin.tactics.config.timeout_duration`, default 2: The timeout for Wingman actions, in seconds.
- `haskell.plugin.tactics.config.hole_severity`, default empty: The severity to use when showing hole diagnostics. These are noisy, but some editors don't allow jumping to all severities. One of `error`, `warning`, `info`, `hint`, `none`.
- `haskell.plugin.tactics.config.max_use_ctor_actions`, default 5: Maximum number of `Use constructor <x>` code actions that can appear.
- `haskell.plugin.tactics.config.proofstate_styling`, default true: Should Wingman emit styling markup when showing metaprogram proof states?
- `ghcide-completions`:
- `haskell.plugin.ghcide-completions.config.snippetsOn`, default true: Inserts snippets when using code completions.
- `haskell.plugin.ghcide-completions.config.autoExtendOn`, default true: Extends the import list automatically when completing a out-of-scope identifier.
- `ghcide-type-lenses`:
- `haskell.plugin.ghcide-type-lenses.config.mode`, default `always`: Control how type lenses are shown. One of `always`, `exported`, `diganostics`.
- `hlint`:
- `haskell.plugin.hlint.config.flags`, default empty: List of flags used by hlint
This reference of configuration can be outdated at any time but we can query the `haskell-server-executable` about what configuration is effectively used:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if we had some way to auto-generate this stuff into the docs. Probably not worth the effort to do fully, but perhaps we could have a halfway house, like:

  • Write a tool like vscode-extension-schema that prints out a markdown or RST table of all the options.
  • Commit the output to the repo. Regenerate it occasionally if we notice it's out of date.
  • Include the generated table into the docs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, but I would do it manually for now in this pr, we could open an issue to track it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking in include the default config/JSON schema directly in docs for reference and link it here, it is easy to regenerate just with actual hls cli output and later we can process it to make it nicer.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but I don't think we should make our users read a JSON file. Either we'll be making a table by hand or we write something to do it 🤷

- `haskell-language-server generate-default-config`: will print the json configuration with all default values. It can be used as template to modify it.
- `haskell-language-server vscode-extension-schema`: will print a json schema used to setup the haskell vscode extension. But it is useful to see what range of values can an option take and a description about it.

Settings like this are typically provided by the language-specific LSP client support for your editor, for example in Emacs by `lsp-haskell`.

### Client options
Expand Down