languages/haskell: remove invalid vim.g options

[siggsy]

Haskell is not configured with lspconfig, but rather with haskell-tools.nvim. This commit fixes "conversion" made in 39efdc799.

Without this, users are met with nvim errors about invalid vim.g options

Sanity Checking

• [x] I have updated the changelog as per my changes
• [x] I have tested, and self-reviewed my code
• [x] My changes fit guidelines found in hacking nvf
• Style and consistency
  • [x] I ran Alejandra to format my code (nix fmt)
  • [x] My code conforms to the editorconfig configuration of the project
  • [x] My changes are consistent with the rest of the codebase
• If new changes are particularly complex:
  • [ ] My code includes comments in particularly complex areas
  • [ ] I have added a section in the manual
  • [ ] (For breaking changes) I have included a migration guide
• Package(s) built:
  • [ ] .#nix (default package)
  • [ ] .#maximal
  • [ ] .#docs-html (manual, must build)
  • [ ] .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • [x] x86_64-linux
  • [ ] aarch64-linux
  • [ ] x86_64-darwin
  • [ ] aarch64-darwin

---

Add a :+1: reaction to pull requests you find important.

[github-actions[bot]]

:rocket: Live preview deployed from da5c91424e6d5028c7cfd171833ac7a71f98cbfc

View it here:

Debug Information

Triggered by: siggsy

HEAD at: v0.8

Reruns: 1558

[siggsy]

Is this here only to have consistent interface with languages? This option is not used, and if it was, we would have to differentiate between configuration with custom plugin (like haskell-tools.nvim) and lspconfig

I have two proposals:

1. Have separate "haskell-tools" server name, which uses the plugin configuration, and hls which uses lspconfig. This makes it confusing, because the referenced "haskell-tools" wont show up on vim.lsp.server.
2. Have a CLEAR distinction between lspconfig and plugin. I'm not sure if plugin options should lie in vim.languages.haskell or somewhere else.

How is this handled in other languages with similar issues?

[sjcobb2022]

@siggsy yes it was purely for consistent interface when I made the changes.

At the moment we do not have any tools type interface, such as for rust (with rustaceanvim) or anything else.

Both rustaceanvim and haskell-tools.nvim support importing the config from vim.lsp.config (https://github.com/mrcjkb/haskell-tools.nvim/commit/53d9888aebe27cd50c0404d88a7aa51d7341784a, https://github.com/mrcjkb/rustaceanvim/pull/660), so I think that keeping it (but leaving it disabled) is probably the best wait to handle these. Would want a second from @horriblename or @NotAShelf for this though.

Perhaps an API such as what we have with the crates.nvim support would be good for this type of setup (for rust as well perhaps)

Where we have

{
     vim.languages.haskell.enable = true; # just enables HLS as a purely with `vim.lsp.config`
     vim.languages.haskell.extensions = {
         haskell-tools-nvim.enable = true; # disables the vim.lsp.enable of hls and uses haskell-tools.
     };
     
     # and for rust if we go this route
     
     vim.languages.rust.enable = true; # enables just rust-analyzer via `vim.lsp.config`
     vim.languages.rust.extensions = {
         rustaceanvim.enable = true; # disable `vim.lsp.enable` of rust-analyzer
         crates-nvim.enable = true;
     };

}

I think that having the command in explicitly is better than not having the command, as this is what we have done for every other language module, and we should keep consistency in that regard.

[horriblename]

Is this here only to have consistent interface with languages?

We can take it back out for now, if it didn't exist before v0.8.

Perhaps an API such as what we have with the crates.nvim support would be good for this type of setup (for rust as well perhaps)

I vaguely recall @NotAShelf wanting to remove the hard dependency we have on some language plugins (rustaceanvim etc.), perhaps this is an opportunity for that?

[sjcobb2022]

I vaguely recall @NotAShelf wanting to remove the hard dependency we have on some language plugins (rustaceanvim etc.), perhaps this is an opportunity for that?

Yeh I think that was on the initial language overhaul branch. Want me to make an issue?

[sjcobb2022]

https://github.com/NotAShelf/nvf/issues/1195

[siggsy]

This configuration now works when users have GHC in path (otherwise hls crashes).