Disable color when `repl-automation` is enabled #1129

New issue

Open

opened 2026-02-10 16:21:29 +00:00 by blokyk · 2 comments

blokyk commented

2026-02-10 16:21:29 +00:00

I just discovered repl-automation and it's great! I'm trying to wrap nix repl for some project, and it makes things easier. However, when it comes to parsing the output, there is still one annoying part: the REPL inserts ANSI escape sequences in the output of a lot of commands (e.g. :p, :env, :bt, etc.). It's more of an annoyance than a big issue, but I can't imagine in what context repl-automation could be used where colors are desired (I'm open to getting more context about the feature tbf)

Describe the solution you'd like

Ideally, color is always disabled in the REPL if the repl-automation experimental feature is enabled.

Describe alternatives you've considered

I tried using NO_COLOR, but this has a very minimal impact on the nix CLI it would seem, and that extends to the REPL. In my opinion, it could be a better solution to support NO_COLOR more broadly (including in the REPL), but that might have a broader scope than doing it based on an experimental feature (at least I imagine, since most of nix doesn't care/understand the NO_COLOR env var).

Additional context

I'm pretty much a complete noob when it comes to C++ specifically, but if this turns out to be something desirable for the project I'd love to work on this when I get time (I already had to dig into the codebase anyway to debug some weird buffering behavior (that's how I discovered repl-automation!))

## Is your feature request related to a problem? Please describe. I just discovered `repl-automation` and it's great! I'm trying to wrap `nix repl` for some project, and it makes things easier. However, when it comes to parsing the output, there is still one annoying part: the REPL inserts ANSI escape sequences in the output of a lot of commands (e.g. `:p`, `:env`, `:bt`, etc.). It's more of an annoyance than a big issue, but I can't imagine in what context `repl-automation` could be used where colors are desired (I'm open to getting more context about the feature tbf) ## Describe the solution you'd like Ideally, color is always disabled in the REPL if the `repl-automation` experimental feature is enabled. ## Describe alternatives you've considered I tried using [`NO_COLOR`](https://no-color.org/), but this has a *very* minimal impact on the nix CLI it would seem, and that extends to the REPL. In my opinion, it could be a better solution to support `NO_COLOR` more broadly (including in the REPL), but that might have a broader scope than doing it based on an experimental feature (at least I imagine, since most of nix doesn't care/understand the `NO_COLOR` env var). ## Additional context I'm pretty much a complete noob when it comes to C++ specifically, but if this turns out to be something desirable for the project I'd love to work on this when I get time (I already had to dig into the codebase anyway to debug some weird buffering behavior (that's how I discovered `repl-automation`!))

raito commented

2026-02-11 13:23:31 +00:00

Owner

Thank you for the report, repl-automation is an internal experimental feature meant for our own testing of the REPL, it was not made to be used externally. We are curious: what sort of automation are you doing with that?

To be completely honest, it's very low priority for us to make repl-automation useful for external consumers, we would rather look how to make the automation they're doing possible with the other supported CLI surface.

Thank you for the report, `repl-automation` is an internal experimental feature meant for our own testing of the REPL, it was not made to be used externally. We are curious: what sort of automation are you doing with that? To be completely honest, it's very low priority for us to make `repl-automation` useful for external consumers, we would rather look how to make the automation they're doing possible with the other supported CLI surface.

blokyk commented

2026-02-11 14:01:45 +00:00

Author

As to why I'm using it: I'm writing a basic debug adapter for nix (so it can be used to "debug" nix eval in e.g. vscode, vim, and other editors supporting the debug adapter protocol). I've seen the Debug Adapter With Nix project that aims to write a nix plugin to make it support DAP directly inside the repl/runtime. However, I don't really have the amount of low-level knowledge (and patience) required to write a plugin myself; so instead, I'm writing a simple adapter that runs the code with nix eval --debugger and then parses the repl output and interacts with it. It's very cursed/scuffed and kinda unstable, but I've just been working on it in my off time for a few days and I already got stepping and stack traces working, and "only" have local variables left before I could see myself using it day to day.

Anyway, all that rambling just to say: while it'd be great to see some new surface exposed for debugging, it's a pretty daunting task, and given that DAWN already stalled I'm not sure how much energy/enthusiasm there is left for this. In other words, I don't see any obvious thing the team or other contributors could be reasonably expected to do without a larger demand/movement.

Ah, that explains why I couldn't find any reference or info about it! And yeah, I kind of expected it'd be pretty low priority, I mostly reported it for the record and to know if it'd be desirable to submit a PR for it. But if it's just an internal tool, I understand that this might not make much sense; so feel free to close this. As to why I'm using it: I'm writing a basic debug adapter for nix (so it can be used to "debug" nix eval in e.g. vscode, vim, and other editors supporting the debug adapter protocol). I've seen the [Debug Adapter With Nix](https://github.com/DieracDelta/DAWN) project that aims to write a nix plugin to make it support DAP directly inside the repl/runtime. However, I don't really have the amount of low-level knowledge (and patience) required to write a plugin myself; so instead, I'm writing a simple adapter that runs the code with `nix eval --debugger` and then parses the repl output and interacts with it. It's very cursed/scuffed and kinda unstable, but I've just been working on it in my off time for a few days and I already got stepping and stack traces working, and "only" have local variables left before I could see myself using it day to day. Anyway, all that rambling just to say: while it'd be great to see some new surface exposed for debugging, it's a pretty daunting task, and given that DAWN already stalled I'm not sure how much energy/enthusiasm there is left for this. In other words, I don't see any obvious thing the team or other contributors could be reasonably expected to do without a larger demand/movement.