Version 2.x.x rewrite released

[mrcjkb]

Hey!

I have decided to revamp this plugin's architecture. The 2.x.x branch is ready.

Improvements

Simplified configuration

No need to call asetup function or call require('haskell-tools').setup_or_attach().
This is all done automatically.

To modify the default configuration, you only need to set vim.g.haskell_tools somewhere in your init.lua.

Internal improvements

This rewrite comes with some internal architectural and type-system related improvements, which should provide more stability.

More info

• See my blog post on the topic.

How to migrate from version 1.x.x

Any options you have passed to setup or start_or_attach can be migrated over to vim.g.haskell_tools.
For example,

require('haskell-tools').start_or_attach {
  tools = {
    -- ...
  },
  hls = {
    on_attach = function(client, bufnr)
    end,
    -- ...
  },
}

or

require('haskell-tools').setup {
  tools = {
    -- ...
  },
  hls = {
    on_attach = function(client, bufnr)
    end,
    -- ...
  },
}

become

vim.g.haskell_tools = {
  tools = {
    -- ...
  },
  hls = {
    ---@param ht is a copy of the haskell-tools module
    on_attach = function(client, bufnr, ht)
    end,
    -- ...
  },
}

Example for lazy.nvim users:

{
  'mrcjkb/haskell-tools.nvim',
  dependencies = {
    'nvim-lua/plenary.nvim',
  },
  branch = '2.x.x', -- Recommended
  config = function() -- Optional, see Advanced configuration
    vim.g.haskell_tools = {
      -- ...
    },
  end,
  -- load the plugin when opening one of the following file types
  ft = { 'haskell', 'lhaskell', 'cabal', 'cabalproject' },
}

Note

• If migrating from start_or_attach, make sure you
  set vim.g.haskell_tools in your regular neovim config, not in ~/after/ftplugin/haskell.lua,
  as the variable needs to be set before the plugin uses it.

Once done, you can delete any calls to setup or start_or_attach.

As before, I recommend to either define keymaps in the ~/after/ftplugin/haskell.lua and ~/after/ftplugin/cabal.lua, or in the vim.g.haskell_tools.hls.on_attach function.

Breaking config changes

• hover.disable has been changed to hover.enable for consistency.
• hls_log (undocumented) has been moved to hls.logfile.

[sondr3]

Why use vim.g.haskell_tools? That feels really strange, none of the other installed plugins I have use that kind of setup and it feels out of place. How can I conditionally load or initialize this plugin now? I would much rather have require("haskell-tools).setup {} to make it explicit and more configurable.

[mrcjkb]

@sondr3 Thanks for your feedback 😃.

Defaulting to setup is an antipattern that has been carried over from a time when Neovim's Lua API had poor Vimscript interoperability. The only reason its use is so common today is thanks to cargo cult programming.
It brings with it a cascade of other antipatterns, like having to initialise fields as nil.
It also makes the (usually) false promise that calling setup more than once with different options will change the configuration.

For this plugin, the most logical time for initialisation is when opening a Haskell or Cabal file. haskell-tools uses Neovim's built-in filetype.lua plugin for this, which is less overhead than setting up autocommands in a setup function.

In case there is a need to conditonally enable individual modules of this plugin, I have enhanced the API in the vim.g.haskell_tools setting, so that many options can be either a value or a function that returns the value.
For example, hls.auto_attach has type boolean | (fun():boolean).

Not calling setup doesn't prevent a plugin from being loaded.
Neovim has built-in support for conditonally loading plugins (see :help packadd).
And most plugin managers have support for that, too.

If you have a use case that isn't covered by that, please let me know, and I will gladly help you find a solution. That's why I published this announcement and am testing it before releasing 😄.

[sondr3]

I just tried using the 2.x.x branch in my config driven by lazy.nvim and tried for a while to get it working without having to change lots of things in my config but didn't find a solution that actually worked. I understand being ideologically opposed to antipatterns like setup and configure, but the ecosystem has landed on it being a thing and this feels like making the wrong tradeoffs; technical over consistency.

[mrcjkb]

but didn't find a solution that actually worked.

Here's a minimal lazy.nvim plugin spec that works just fine with the 2.x.x branch:

 {
    'mrcjkb/haskell-tools.nvim',
    branch = '2.x.x',
    init = function()
      vim.g.haskell_tools = {
        -- config goes here
      }
    end,
    dependencies = {
      'nvim-lua/plenary.nvim',
    },
}

What exactly are you having trouble with?

I understand being ideologically opposed to antipatterns like setup and configure, but the ecosystem has landed on it being a thing and this feels like making the wrong tradeoffs; technical over consistency.

• This has nothing to do with "ideology". It's about maintainability of my project, and leaving less room for bugs.
• Regarding "consistency": Pretty much all Vimscript plugins use vim.g for configuration. And a bunch of lua plugins are moving away from the setup antipattern - I expect that number to grow in the near future. The Neovim ecosystem has always been evolving at a fast pace.

[sondr3]

Don't know what to tell you, I tried that but haskell-tools isn't picked up for me as a provider when used in combination with mason/nvim-lspconfig/lazy.nvim, so nothing happens. 🤷

[mrcjkb]

Just had a look at your dotfiles.
Here's your problem:

require("lazy").setup("config.plugins", {
  defaults = { lazy = true }, -- <-- THIS
  -- ...
})

I will add a note for lazy.nvim users to the readme. Thanks for your persistence trying to solve this by the way. This is giving me valuable information 😄.

If you want to keep that setting, you can add ft = { 'haskell', 'lhaskell', 'cabal', 'cabalproject', } to your haskell-tools plugin spec. That will tell lazy to load the plugin when opening one of those filetypes.

haskell-tools.nvim is lazy by design. It will only initialise when you open a Haskell or Cabal file.
Which is one of the reasons version 2.x.x no longer forces the setup antipattern on people who don't use lazy.nvim.

In your haskell-tools plugin spec, I don't think you need to call

lsp.fidget()
lsp.signature()
lsp.null_ls()

and you can call

local lsp = require("config.plugins.lsp")

in the on_attach function, to make sure you don't load the module too eagerly.

It looks like you're still calling require('haskell-tools').setup() in your plugin.lsp module, by the way.

[sondr3]

Yeah, the dotfiles-repo didn't include the final code, I just quickly updated and pushed. I definitely tried the ft = {} thing yesterday, but guess I did it wrong. It works now, thanks for the help debugging 🙂

[sondr3]

Would you be open to make an alias for vim.g.haskell_tools to require("haskell-tools).configure{}? I have read some of the criticism for setup{} and feel like this might be a okay compromise.

[mrcjkb]

vim.g.haskell_tools has to be set before you call require('haskell-tools'). So require('haskell-tools').configure{} would do nothing.
I would have to put such an alias in a different module, e.g. require('haskell-tools.config').configure{}.

I'd prefer not to do that, as all I see it do is add overhead and boilerplate. But I'm open to it if there's a use case I'm not aware of.

[bolt12]

I don't understand lua, nvim enough to be able to figure this out for myself. It seems the README quickstart documentation is not up to date, after reading this discussion.

So I ask: What's an (minimal) example of a configuration that just works?

I am using NixOS + home-manager not sure if that helps/matters.

[mrcjkb]

The haskell-tools package on nixpkgs is at version 1.9.1, which would explain why it doesn't work out of the box.
I'll see if I can get it updated...

[mrcjkb]

NixOS/nixpkgs#256325

[bolt12]

Thank you for your time on this!

[bolt12]

Just want to say that I managed to get it to work!

[mrcjkb]

Awesome! Thanks for the update! 🙏