fix(haskell): Update haskell-tools.nvim to v2.0.0

[Per48edjes]

📑 Description

Update the Haskell pack's init.lua to reflect the changes made in mrcjkb/haskell-tools.nvim#227. (The changes herein are lifted directly from the plugin creator's suggested lazy.nvim config.)

ℹ Additional Information

• LSP: Unable to "hover" when a local definition or type definition's file path contains url encoded characters mrcjkb/haskell-tools.nvim#238 prompted an updated (for me) from v1.0.0 to v2.0.0
• This is my first time contributing to this project, so any guidance is most appreciated!
  • Caveat lector: As someone who just recently transitioned from vim to Neovim, I'm also a newbie when it comes to Lua configs... 😬

[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.

[mrcjkb]

Nit: I would suggest changing the PR title's prefix to chore(deps):, as this is not really a bug fix.

[Per48edjes]

Nit: I would suggest changing the PR title's prefix to chore(deps):, as this is not really a bug fix.

Fair enough; will update the type to chore but I think this project wants the scope to be the existing enclosing folder.

[Uzaaft]

@Per48edjes Your first PR title was fine. :)

[Uzaaft]

1. Add optional to telescope.nvim
2. I don't think utils.list_insert_unique(astronvim.lsp.skip_setup, "hls") is inplace. It should be
   astronvim.lsp.skip_setup = utils.list_insert_unique(astronvim.lsp.skip_setup, "hls")

[Per48edjes]

1. Add optional to telescope.nvim
2. I don't think utils.list_insert_unique(astronvim.lsp.skip_setup, "hls") is inplace. It should be
   astronvim.lsp.skip_setup = utils.list_insert_unique(astronvim.lsp.skip_setup, "hls")

Incorporated these in ead0450! Happy to continue moving this forward -- would need some direction on whether this is good as is or whether we're trying to throw vim.g in config.

[mrcjkb]

1. Add optional to telescope.nvim
2. I don't think utils.list_insert_unique(astronvim.lsp.skip_setup, "hls") is inplace. It should be
   astronvim.lsp.skip_setup = utils.list_insert_unique(astronvim.lsp.skip_setup, "hls")

Incorporated these in ead0450! Happy to continue moving this forward -- would need some direction on whether this is good as is or whether we're trying to throw vim.g in config.

I don't use AstroNvim, so I don't feel strongly about this.
My recommendation would be to either one of

• set vim.g.haskell_tools in config (by merging a default with the opts argument - this is fine for a lazily initialized filetype plugin)
• or incorporate my second suggestion vim.g.haskell_tools = vim.g.haskell_tools or { ... } in init, so that users can override it if they want.

Either way, the previous version of this package was not user-configurable, so I would say go with YAGNI for now.

On a related note: haskell-tools will soon auto-discover DAP configurations by default if nvim-dap is installed and a haskell-debug-adapter executable is detected, see: mrcjkb/haskell-tools.nvim#249
So the call to ht.dap.discover_configurations will be redundant after the 2.1.0 release.

[Uzaaft]

Appreciate the heads up on the v2.1 launch @mrcjkb

[Uzaaft]

I'll leave the last word to @mrcjkb He knows his plugin well enough. Any thoughts about where the vim.g code should go, etc?

[mrcjkb]

I'll leave the last word to @mrcjkb He knows his plugin well enough. Any thoughts about where the vim.g code should go, etc?

Let's merge this as is for now and I'll open a separate PR after the 2.1 haskell-tools release 😄

[Uzaaft]

I'll leave the last word to @mrcjkb He knows his plugin well enough. Any thoughts about where the vim.g code should go, etc?

Let's merge this as is for now and I'll open a separate PR after the 2.1 haskell-tools release 😄

Looking forward to it!

[Per48edjes]

Thanks for all the help @mrcjkb & @Uzaaft ! 🙏