!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

681 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://nixos.org/manual/nixpkgs/unstable/#haskell | Current PR: https://github.com/nixos/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Ahaskell-updates | Maintainer Docs: https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/HACKING.md | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | Merger Schedule: https://cloud.maralorn.de/apps/calendar/p/H6migHmKX7xHoTFa/dayGridMonth/now | Join #haskell.nix:libera.chat for question about the alternative haskell.nix infrastructure134 Servers

Load older messages


SenderMessageTime
1 Dec 2025
@mequbic:matrix.orgiqubic (she/her) As the GitHub issue notes, Day01 and Common.* at the top are being rendered with haskell-constructor-face 00:25:17
@me:linj.techlinjThe easiest way to downgrade hls is to switch to an old nixpkgs commit whose hls is old, I guess00:25:44
@mequbic:matrix.orgiqubic (she/her)I see.00:25:55
@mequbic:matrix.orgiqubic (she/her) 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. 00:27:36
@alex:tunstall.xyzAlex
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.

01:03:14
@mequbic:matrix.orgiqubic (she/her)Yeah... if there's a way to disable that to test things out, I'd love to.01:03:56
@alex:tunstall.xyzAlex
In reply to @mequbic:matrix.org
Yeah... if there's a way to disable that to test things out, I'd love to.
Try adding haskell.plugin.semanticTokens.globalOn: false to your HLS config.
(See https://haskell-language-server.readthedocs.io/en/latest/configuration.html#generic-plugin-configuration, the plugin isn't listed in the docs but I found its config option in the PR.)
01:09:59
@mequbic:matrix.orgiqubic (she/her)Where is the default HLS config?01:10:19
@alex:tunstall.xyzAlexNo idea. I think that would depend on your editor or how you're starting the LSP server, so you should probably consult the relevant section of your editor's manual (since most editors start the server themselves).01:12:29
@alex:tunstall.xyzAlexBtw it seems to be default disabled on most GHC versions.01:13:43
@mequbic:matrix.orgiqubic (she/her)I'm using Emacs LSP-Mode.01:14:09
@mequbic:matrix.orgiqubic (she/her)https://emacs-lsp.github.io/lsp-mode/01:14:22
@alex:tunstall.xyzAlex Not familiar with Emacs, sorry.
You could perhaps also try checking for changes in the syntax highlighting (or in the treesitter highlighter, if the editor uses that).
01:16:36
@mequbic:matrix.orgiqubic (she/her)I'm not using treesitter. In fact, I explicitly just turned that off recently.01:17:10
@acidbong:envs.net@acidbong:envs.net moin
for defining variables that aren't supposed to be exported (like in single-file programs), what's more idiomatic/common in haskell: multiple top-level assignments before the main function or let..in block(s)?
06:08:05
@b:chreekat.netchreekat

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
07:46:35
@acidbong:envs.net@acidbong:envs.net
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
oh damn, i confused the room
09:06:53
@acidbong:envs.net@acidbong:envs.net left the room.09:08:17
2 Dec 2025
@mequbic:matrix.orgiqubic (she/her)

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
  ];
}
06:04:21
@mequbic:matrix.orgiqubic (she/her)That's pulling in GHC 9.10.306:04:51
@mequbic:matrix.orgiqubic (she/her) After doing some work on a Haskell program of mine, I got this message dumped into stderr:
https://dpaste.alwaysdata.org/2T0oxtWG
06:05:52
@mequbic:matrix.orgiqubic (she/her) * That's pulling in GHC 9.10.3 from nixpkg-unstable 06:06:20
@mequbic:matrix.orgiqubic (she/her) At least, that's the what I see in the error log of Emacs's lsp-mode 06:06:31
@mequbic:matrix.orgiqubic (she/her)Seems to be related to HLint, as I was attempting to do an HLint refactor when the LSP crashed.06:07:31
@mequbic:matrix.orgiqubic (she/her)Also, I found this: https://github.com/haskell/haskell-language-server/issues/467406:07:36
@mequbic:matrix.orgiqubic (she/her)What should I do here?06:08:02
@maralorn:maralorn.demaralorn

iqubic (she/her): One of

  1. disable the hlint plugin in your editor config.

  2. disable the hlint plugin by locally overriding the hls package

  3. disable the hlint plugin by adding (and upstreaming) an override in nixpkgs

  4. wait for the hls release which disables the hlint plugin to propagate to you.

  5. or 4. needs to happen and needs to be backported to 25.11 because we shouldn’t have a broken hls there.

08:43:21
@maralorn:maralorn.demaralornArgh, matrix. Why do you do this to me? Why do you destroy my carefull numbering.08:43:58
@maralorn:maralorn.demaralorn iqubic (she/her): Sadly hls is kinda in a bad place because I am in a bad place. :-/. 08:45:28
@maralorn:maralorn.demaralornAs in: My other duties are completely preventing me from fixing stuff in nixpkgs.08:46:35

There are no newer messages yet.


Back to Room ListRoom Version: 6