Allow turning on the debugger in the middle of a REPL session #1198

New issue

Open

opened 2026-04-28 11:20:40 +00:00 by blokyk · 1 comment

blokyk commented

2026-04-28 11:20:40 +00:00

Member

Sometimes I'm trying out some code in the REPL, and suddenly something throws for reasons unbeknownst to me. I'd like to be able to investigate that without having to quit the debugger, relaunch it with --debugger, and type all the previous local bindings/expressions.

Describe the solution you'd like

Add a :dbg or :de command that sets the REPL in debugger mode, much like how nix repl --debugger <args> would have, ideally with the same local bindings we currently have.

Describe alternatives you've considered

Always using the repl in debugger mode (e.g. by making an alias nix-repl=nix repl --debugger) is not a good solution, because sometimes i don't care that something throws an error or whatever.

Additional context

If I remember correctly, debuggability is current done by inserting special nodes in expressions so we can step through them, but is this done at parsing time, eval time, or a secret third option? If it's either of the first two, then this feature request is basically impossible for now.

Assuming that is possible, Is this even currently doable if the expression has already thrown? I imagine the expression that error'd is cached and thus debugging it would be impossible, but can someone confirm it? if it doesn't work for expressions that have already thrown, then this is probably pretty useless :/

## Is your feature request related to a problem? Please describe. Sometimes I'm trying out some code in the REPL, and suddenly something throws for reasons unbeknownst to me. I'd like to be able to investigate that without having to quit the debugger, relaunch it with `--debugger`, and type all the previous local bindings/expressions. ## Describe the solution you'd like Add a `:dbg` or `:de` command that sets the REPL in debugger mode, much like how `nix repl --debugger <args>` would have, ideally with the same local bindings we currently have. ## Describe alternatives you've considered Always using the repl in debugger mode (e.g. by making an alias `nix-repl=nix repl --debugger`) is not a good solution, because sometimes i don't care that something throws an error or whatever. ## Additional context If I remember correctly, debuggability is current done by inserting special nodes in expressions so we can step through them, but is this done at parsing time, eval time, or a secret third option? If it's either of the first two, then this feature request is basically impossible for now. Assuming _that_ is possible, Is this even currently doable if the expression has already thrown? I imagine the expression that error'd is cached and thus debugging it would be impossible, but can someone confirm it? if it doesn't work for expressions that have already thrown, then this is probably pretty useless :/

jade added the

Area/repl

label

2026-04-28 14:55:29 +00:00

jade commented

2026-04-28 14:57:26 +00:00

Owner

Hmmmm, is this actually impossible? Or do we just have to invoke a reload and recreate the evaluator or something like that? It doesn't feel as impossible to me as when I read the issue title.

I do know that the debugger is basically a separate evaluator mode so it definitely is pretty invasive and you can't do it without restarting the evaluator, but you can restart the evaluator without killing the entire process.

Hmmmm, is this actually impossible? Or do we just have to invoke a reload and recreate the evaluator or something like that? It doesn't feel as impossible to me as when I read the issue title. I do know that the debugger is basically a separate evaluator mode so it definitely is pretty invasive and you can't do it without restarting the evaluator, but you can restart the evaluator without killing the entire process.

jade added the

Area/repl/debugger

label

2026-04-28 14:58:17 +00:00