git-hooks.nix VS haskell-tools.nvim

> Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here".

I experienced a similar situation last week with git-hooks.nix[1], a pre-commit integration for Nix.

I wanted to run biome[2] checks on my repository during pre-push so I wrote a custom hook because git-hooks.nix has pre-defined integrations with prettier and rome, but not biome.

Or that's what I thought. I eventually found out that the rome hook is actually referred as "rome" everywhere but calls biome instead[3]. This wasn't documented anywhere, so I opened an issue[4] suggesting to rename the hook to "biome" and keep the former for backwards compatibility reasons.

As of today, this has been acknowledged by one of the maintainers, whose sole feedback has been to "thumb down" the issue.

TL;DR: It's not just the documentation, but also the code not doing what you would expect. It also seems there's no means to improve the situation other than just forking the project since there's also clearly some kind of communication problem.

[1] https://github.com/cachix/git-hooks.nix

Anyone who already uses Nix and Flakes can use this integration. Anyone who doesn't use Nix can just ignore me, because I'm not here to try converting unconvinced folks.

I don't think it does. I might look into implementimg it though, because I use pre-commit-hooks.nix in my own projects' CI.

> My least favourite bug is that it doesn't always play nicely with NixOS [1], and the maintainer locked me out of the issue for pointing it out.

Oof. Does this solve the problem https://github.com/cachix/pre-commit-hooks.nix (using Nix to manage dependencies)?

I was looking at pre-commit the other day, and wanted to incorporate it into the Nix setup of my projects.

Was it not possible to use something like this? https://github.com/cachix/pre-commit-hooks.nix

Maybe consider adding this to https://github.com/cachix/pre-commit-hooks.nix once you feel it's mature enough.

haskell-tools.nvim 1.10.0 now has the ability to discover nvim-dap launch configurations for haskell-debug-adapter from cabal and stack projects.

For language-specific plugins and configs, it can make sense to load them only when actually working with the respective language. For this reason, I have added better support for setting up haskell-tools.nvim in ~/.config/nvim/ftplugin/haskell.lua.

I thought it would be neat if there were a way to update all haskell-language-server evalCommand code lenses at once. So I implemented it in haskell-tools.nvim.

When I added some EmmyLua docs to one of my plugins (to generate Vimdoc using lemmy-help), I noticed lua-language-server was giving me diagnostics based on my documentation. This was something I was not getting from linters like luacheck. So I asked myself, "Can I leverage lua-language-server and EmmyLua to statically type check my Lua code?"

I just completed work on some new features for my haskell-tools.nvim plugin!

haskell-tools.nvim