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 39efdc7.

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

Sanity Checking

• I have updated the changelog as per my changes
• I have tested, and self-reviewed my code
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • 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)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

🚀 Live preview deployed from da5c914

View it here:

Debug Information

Triggered by: siggsy

HEAD at: v0.8

Reruns: 1558

[siggsy]

This is also odd. As far as I understand haskell-language-server-wrapper only searches for hls and starts it. So we still have to provide haskell-language-server in our projects. Is this then really necessary? Should I remove this aswell? If anything, this adds 6.73GB to the nixos configuration

[siggsy]

Just tested it. Without the cmd option, nvim behaves the same

[sjcobb2022]

I believe that we should still reference in manually, like the rest of the packages.

      cmd = [(getExe' pkgs.haskellPackages.haskell-language-server "haskell-language-server") "--lsp"];

so that we are explicit

[siggsy]

The problem is that the hls is compiled for specific ghc version. If we do specify it like you suggested, then you would be stuck on a specific ghc, and would prevent haskell-tools choosing appropriate hls for haskell projects.

[sjcobb2022]

That's a fair point and a little bit of a weak suit for HLS imo haha.

Perhaps we could make it a string instead to allow the user to change it if need be.

e.g.

cmd = "haskell-language-server --lsp"

and then the plugin can throw an error if necessary.

[horriblename]

If we do specify it like you suggested, then you would be stuck on a specific ghc, and would prevent haskell-tools choosing appropriate hls for haskell projects.

I'm pretty sure haskell-tools looks for a usable hls in PATH regardless of whether cmd is set. Or I could be misremembering.

Either way, the purpose of the language modules are to provide plug-and-play defaults. In this case the closest we can get is having a default hls so that there is at least some chance of it working ootb for someone.

[siggsy]

Since haskell-tools supports it, the hls configuration was moved to vim.lsp.servers to allow users to override cmd, and avoid unnecessary dependencies

[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 (mrcjkb/haskell-tools.nvim@53d9888, mrcjkb/rustaceanvim#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]

#1195

[siggsy]

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