Should we consider deriving the mode from nix-mode?
Opened this issue · 2 comments
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)
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.
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.