fix(haskell): make haskell-tools respect the options table

[mrcjkb]

📑 Description

This PR is stacked on top of #570, which should be merged first.

• As discussed in fix(haskell): Update haskell-tools.nvim to v2.0.0 #553 (comment), the haskell-tools plugin is not user-configurable
• This PR uses the same method as the java package to allow users to configure the plugin through an opts table in community.lua.

As mentioned in #553, I don't feel strongly about this, so please close this PR if you don't agree with this approach.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Proper usage of opts table rather than setting things up with the config function.

[mehalter]

small minor change, but seems alright.

Note: This does add a weird level of abstraction that isn't accounted for in the haskell-tools documentation which could be something that will confuse users, but I'll leave that decision up to the community since core AstroNvim doesn't maintain these packages. As an alternative, with the original approach the user can use the config function to modify the default vim.g.haskell_tools variable.

[mrcjkb]

This does add a weird level of abstraction that isn't accounted for in the haskell-tools documentation which could be something that will confuse users

That's a good point...

As an alternative, with the original approach the user can use the config function to modify the default vim.g.haskell_tools variable.

I'm not really familiar with lazy.nvim. Wouldn't it be possible for users to override the config function with this approach?

[mehalter]

@mrcjkb Yes they can, but it it will override the original config function. Lazy will extend the opts table but override the config function. So the user will have to specifically remember to set the vim.g.haskell_tools variable with the opts that are passed in rather than knowing that it is already set.

[mrcjkb]

Oh, I see. That does seem a bit unergonomic...

[mehalter]

Maybe what we should do @mrcjkb is just keep it how it was with the init function setting it but using tbl_deep_extend on the current value of vim.g.haskel_tools to keep what's already set. Then the user can configure it through the config function if they want or they could just configure it through the options table like normal. That's a bit more of a normal way to approach it

[mrcjkb]

Although... If I understand correctly, this means that they would also have to remember to call setup, if overriding the config function for other plugins?

[mehalter]

  {
    "mrcjkb/haskell-tools.nvim",
    dependencies = {
      "nvim-lua/plenary.nvim",
      { "nvim-telescope/telescope.nvim", optional = true },
      { "mfussenegger/nvim-dap", optional = true },
    },
    version = "^2",
    init = function()
      astronvim.lsp.skip_setup = utils.list_insert_unique(astronvim.lsp.skip_setup, "hls")
      vim.g.haskell_tools = vim.tbl_deep_extend("keep", vim.g.haskell_tools or {}, {
        hls = {
          on_attach = function(client, bufnr, _) require("astronvim.utils.lsp").on_attach(client, bufnr) end,
        },
      })
    end,
    -- load the plugin when opening one of the following file types
    ft = { "haskell", "lhaskell", "cabal", "cabalproject" },
  },

This is probably a good spec to use. It doesn't enable the opts table but enables the options table which is the place that more aligns with the haskell-tools.nvim docs.

Also to answer your most recent message, yes. If the user overrides the config functionthey do have to remember to call the setup function. But it's more obvious that the opts are what would go there rather than the opts getting set for a random variable.

[mrcjkb]

Maybe what we should do @mrcjkb is just keep it how it was with the init function setting it but using tbl_deep_extend on the current value of vim.g.haskel_tools to keep what's already set.

You mean to set the default in init and then deep extend in config?

Sounds fine to me.

[mehalter]

No @mrcjkb , I sent a config that illustrates what I said. I think configuring the options through the opts table may seem obvious to some users, but it very much goes against the docs and sorta blends a couple different ideas together and could make things more confusing as to why it does the things it does.

[mehalter]

also instead of branch = "2.x.x", it probably makes more sense to do verion = "^2". This aligns more with lazy methodology and is a bit cleaner

[mrcjkb]

No @mrcjkb , I sent a config that illustrates what I said. I think configuring the options through the opts table may seem obvious to some users, but it very much goes against the docs and sorta blends a couple different ideas together and could make things more confusing as to why it does the things it does.

Lgtm. I'll update later today when I'm back home.

[mehalter]

ok cool no worries, I can actually make the push now and get this merged in. Thanks for brainstorming through this with me!

[mrcjkb]

ok cool no worries, I can actually make the push now and get this merged in. Thanks for brainstorming through this with me!

Thanks 🙏