Should we consider deriving the mode from nix-mode?

[purcell]

It's entirely appropriate for nix-ts-mode to be a separate package from nix-mode because of its strict dependencies on Emacs 29 and treesitter. But should there be any connection between them? There are arguments for and against.

Some popular major modes have become quite crufty, monolithic and poorly-maintained over time (cough, Haskell, for example), so it's healthy for there to be a clean break in those cases, with a smaller resulting package that gives people just what current users want — and often those users are relying on LSP, reformatters and other more modular tooling, rather than piles of emacs lisp wizardry.

In contrast, clojure-ts-mode has built on top of clojure-mode, which is well-maintained, and this makes it quite easy to switch to: all the underlying features work the same way.

nix-mode is still quite actively maintained and probably has a lot of useful stuff that isn't accessible to people who use nix-ts-mode, since there's a fresh keymap etc. nix-ts-mode could do the same as clojure-ts-mode in this regard.

My personal preferred outcome would be a more modular world in which we can install a minimal major mode for highlighting, indentation and hooks, and then pick and choose extra packages for extended functionality according to our needs/preferences.

As an example, flycheck users have long been able to install add-on flycheck packages for various languages without each major mode needing to grow an opinionated dependency on flycheck: now that flycheck is fading out, that would have left a mess. I noticed that nix-mode has grown a package dependency on transient, simply because nix-flake.el uses it, while that module doesn't rely on much beyond nix-executable as far as I can see: nix-flake could easily be a separate useful package, in theory at least.

I'm wondering what folks think? Also pinging @matthewbauer and @akirak because they're familiar with nix-mode and these topics, though it's super early days for this repo and Rémi is fully entitled to keep things simple (plus I'll still be using nix-ts-mode for my purposes!).

(This was prompted by a fediverse conversation here: https://mastodon.social/@acowley/110979045009664915)

[remi-gelinas]

I'm definitely interested in the discussion, and I have no strong opinions one way or the other!

I initially chose not to derive it from nix-mode because of the strict dependencies, as you mentioned, but also because nix-mode includes a lot of builtin utilities and cruft for interacting with Nix repos through Emacs that I didn't necessarily want to require users to install as well.

I typically err on the side of the old UNIX philosophy of keeping tools good at doing one thing really well, so my intention for this package was to provide great treesitter-based syntax highlighting, sexp movement, and indentation. Syntax highlighting and interaction features that get out of your way, if that makes sense.

Totally open to deriving it from nix-mode in future if there's enough pros to warrant it - but I would also personally prefer to see nix-mode split up into a core mode package we could derive from, and the extra utilities spun off into addon packages that are not required.

[akirak]

I noticed that nix-mode has grown a package dependency on transient, simply because nix-flake.el uses it, while that module doesn't rely on much beyond nix-executable as far as I can see: nix-flake could easily be a separate useful package, in theory at least.

nix-flake.el was initially my work, but thereafter I started working on its replacement, which aims at providing a more comprehensive interface to nix commands (but can be more opinionated). I will be totally fine with nix-flake.el being separated/extracted from the main nix-mode package. I have not been putting any effort on nix-flake.el for more than a year, and I am not sure if anyone is using it.