| 1 Dec 2025 |
Alex | No 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 | Btw it seems to be default disabled on most GHC versions. | 01:13:43 |
iqubic (she/her) | I'm using Emacs LSP-Mode. | 01:14:09 |
iqubic (she/her) | https://emacs-lsp.github.io/lsp-mode/ | 01:14:22 |
Alex | 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 |
iqubic (she/her) | I'm not using treesitter. In fact, I explicitly just turned that off recently. | 01:17:10 |
@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 |
chreekat | 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:
- 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
- Anything that needs a do block usually goes on the top level
- 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
- I usually put top-level helpers after the function they are helping, and I usually use let instead of where.
- Nesting lets and wheres is awful
| 07:46:35 |
@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:
- 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
- Anything that needs a do block usually goes on the top level
- 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
- I usually put top-level helpers after the function they are helping, and I usually use let instead of where.
- Nesting lets and wheres is awful
oh damn, i confused the room | 09:06:53 |
| @acidbong:envs.net left the room. | 09:08:17 |
| 2 Dec 2025 |
iqubic (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 |
iqubic (she/her) | That's pulling in GHC 9.10.3 | 06:04:51 |
iqubic (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 |
iqubic (she/her) | * That's pulling in GHC 9.10.3 from nixpkg-unstable | 06:06:20 |
iqubic (she/her) | At least, that's the what I see in the error log of Emacs's lsp-mode | 06:06:31 |
iqubic (she/her) | Seems to be related to HLint, as I was attempting to do an HLint refactor when the LSP crashed. | 06:07:31 |
iqubic (she/her) | Also, I found this: https://github.com/haskell/haskell-language-server/issues/4674 | 06:07:36 |
iqubic (she/her) | What should I do here? | 06:08:02 |
maralorn | iqubic (she/her): One of
-
disable the hlint plugin in your editor config.
-
disable the hlint plugin by locally overriding the hls package
-
disable the hlint plugin by adding (and upstreaming) an override in nixpkgs
-
wait for the hls release which disables the hlint plugin to propagate to you.
-
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 | Argh, matrix. Why do you do this to me? Why do you destroy my carefull numbering. | 08:43:58 |
maralorn | iqubic (she/her): Sadly hls is kinda in a bad place because I am in a bad place. :-/. | 08:45:28 |
maralorn | As in: My other duties are completely preventing me from fixing stuff in nixpkgs. | 08:46:35 |
iqubic (she/her) | I see | 16:50:48 |
iqubic (she/her) | maralorn: Would you be able to tell me how to modify my shell.nix to disable HLS for now? | 16:54:57 |
maralorn | disable HLS or disable hlint? | 17:00:35 |
maralorn | iqubic (she/her): You need to apply haskell.lib.compose.disableCabalFlag "hlint" to hls. | 17:03:08 |
maralorn | e.g. packages = p: [(haskell.lib.compose.disableCabalFlag "hlint" p.haskell-language-server)] or something similar. | 17:03:51 |
maralorn | * e.g. buildInputs = [(haskell.lib.compose.disableCabalFlag "hlint" pkgs.haskell-language-server)] or something similar. | 17:04:11 |
maralorn | * e.g. buildInputs = [(pkgs.haskell.lib.compose.disableCabalFlag "hlint" pkgs.haskell-language-server)] or something similar. | 17:04:22 |
iqubic (she/her) | Actually, I can just tell Emacs to disallow HLint code action stuff. Would that be sufficient for now? | 17:06:59 |