HLS configuration options and `lsp-haskell`

[dschrempf]

Probably related: #99.

I was worried about the alignment of configuration options in lsp-haskell, and the actuall options ("Configuration") provided by HLS.

Looking into lsp-haskell.el, it seems like a good chunk of work to drag along the configuration options, which are exposed by HSL, on the Emacs side. I saw that there is actually an HLS command (!) generating the extension schema for VSCode

haskell-language-server vscode-extension-schema

First, I was wondering what is the reason why this is VSCode-sepcific? Actually, I was thinking we should provide this schema in an editor agnostic way (JSON I guess; the VSCode schema comes pretty close but some information we have in lsp-haskell.el is actually not available in the VSCode extension schema).

What do you think?

PS: There is a separate command printing the default configuration, but it is even less useful for scraping the available configuration options.

[dschrempf]

Maybe of interest to @asadoll , because they implemented many of the options into lsp-haskell.

[michaelpj]

There's a elisp snippet in lsp-mode that generates options from a vscode schema, what we have now is generated using that. But it's a bit of a pain, manual, and also somewhat irrevocably tied to the version of HLS you do it with (not so worried about this). I would definitely welcome some improvements on this front. Even if it was pulling the option definitions out into a separate file and adding a script to regenerate them.

[dschrempf]

Yes, that's what I thought about. However, I cannot see how we then discriminate between the configurations options of different HLS versions. One can extract the set of configuration options from a specific HLS version, but from many? Would it be enough to only extract the set of options from the latest HLS release?

[michaelpj]

Yes, that's what I've done in the past. It's not perfect but I think it's the best thing we can do.