Is it possible to downgrade my Haskell-Language-Server version for testing purposes? I'm using this shell.nix:

{ pkgs ? import <nixpkgs> {} }:
let
  src = pkgs.nix-gitignore.gitignoreSource [] ./.;
  myPkg = pkgs.haskellPackages.callCabal2nix "aoc25" src {};
in
pkgs.stdenv.mkDerivation {
  name = "aoc-shell";

  buildInputs = [
    myPkg.env.nativeBuildInputs

    pkgs.haskell-language-server
    pkgs.cabal-install
    pkgs.hlint
  ];
}

In reply to @mequbic:matrix.org
The issue is that I don't think these symbols should be colored with the haskell-constructor-face, because those are constructors. They are module names.

I don't know much about how HLS is implemented, but it seems like you may be able to disable the semantic highlighting by removing the plugin that implements it (see https://github.com/haskell/haskell-language-server/pull/3892) from your HLS installation. I assume there is a way of overriding the list of installed HLS plugins in Nixpkgs.

If that resolves your issue, then it's in some way caused by the semantic highlighting. If the issue persists, I find it highly doubtful that HLS is responsible.

In reply to @mequbic:matrix.org
Yeah... if there's a way to disable that to test things out, I'd love to.

Probably not the right room to be asking (sorry), and I'm not sure there is an option that's more idiomatic. But I'll give my own recommendations and heuristics:

1. Always use explicit export lists so you only export the things you want exported. It's helpful to the compiler as well as your future self
2. Anything that needs a do block usually goes on the top level
3. lets and wheres are good for one-line unpacking or manipulating of function arguments, but it gets confusing if you can't see the place where the arguments are declared on the same screen
4. I usually put top-level helpers after the function they are helping, and I usually use let instead of where.
5. Nesting lets and wheres is awful

In reply to @b:chreekat.net

Probably not the right room to be asking (sorry), and I'm not sure there is an option that's more idiomatic. But I'll give my own recommendations and heuristics:

1. Always use explicit export lists so you only export the things you want exported. It's helpful to the compiler as well as your future self
2. Anything that needs a do block usually goes on the top level
3. lets and wheres are good for one-line unpacking or manipulating of function arguments, but it gets confusing if you can't see the place where the arguments are declared on the same screen
4. I usually put top-level helpers after the function they are helping, and I usually use let instead of where.
5. Nesting lets and wheres is awful

Well... the Haskell LSP is throwing errors for me on NixOS. I have it installed via my nix-shell:

{ pkgs ? import <nixpkgs> {} }:
let
  src = pkgs.nix-gitignore.gitignoreSource [] ./.;
  myPkg = pkgs.haskellPackages.callCabal2nix "aoc25" src {};
in
pkgs.stdenv.mkDerivation {
  name = "aoc-shell";

  buildInputs = [
    myPkg.env.nativeBuildInputs

    pkgs.cabal-install
    pkgs.haskell-language-server
    pkgs.hlint
    pkgs.ormolu
  ];
}