Why debugging makes you save first

Start a debug run on an unsaved buffer in DetentShell and you get a prompt: save, or cancel. There is no third button. This generates questions, so here’s the reasoning in one place.

A PowerShell breakpoint binds to a script path and a line number. That’s the engine’s contract, not ours. Text sitting unsaved in an editor has neither a path nor stable lines, so there is nothing for a breakpoint to bind to.

Tools that paper over this do something lossy underneath. Some write your buffer to a shadow file and debug that. Some debug the buffer while your breakpoints silently reference the stale copy on disk. Both roads lead to the same place: execution stops on a line that doesn’t match what’s on your screen, or glides through a breakpoint you can see right there. If you’ve ever debugged the wrong version of your own script, you know the feeling. It doesn’t present as a tool bug. It presents as you losing your mind.

So the contract stays visible. The gutter’s dots are engine breakpoints on the saved file, and the debugger stops on them because screen and engine agree about what line 7 contains. Save-before-debug is the one seam where you feel the contract, and it’s a prompt rather than an auto-save because saving has consequences of its own. Maybe a file watcher deploys on save. Maybe the buffer is a scratch experiment. The tool asks; you decide. What it won’t do is debug a fiction.

Day to day, breakpoint handling is what you’d expect. Click the gutter or press F9 to toggle. Disable a breakpoint and its dot dims but stays put, present and unarmed, and that distinction is exposed to screen readers as text too. Remove All, Enable All, and Disable All live on the Debug menu, greyed out when the breakpoint set is empty rather than pretending to work. List Breakpoints prints the set to the console where it can be copied into a ticket.

One prompt, in exchange for the debugger never stopping anywhere you didn’t mean.

← All posts