Only print relevant frames with the `:bt` debugger command #1199

New issue

Open

opened 2026-04-28 11:43:03 +00:00 by blokyk · 1 comment

blokyk commented

2026-04-28 11:43:03 +00:00

Member

When debugging in the middle of the call stack, trying to understand the frames around you using :bt can be a little frustrating, since you might need to scroll quite a bit to find the slice you're interested in. We could instead only print the stack around the current frame by default, with some syntax to control the range and print other parts of the stack.

Describe the solution you'd like

There's multiple parts to this:

By default, when using :bt, only print the frames around (e.g. 1 frame up, 1 frame down) the current one (as set by :st <n>), maybe with the non-current frames faded (i.e. with ANSI_FAINT/\e[2m)
Allow passing relative frame ranges to :bt, such that you can print more or less frames around the current one; this could be something like :bt N for printing N frames up (maybe with -N for down? not that useful but eh), and :bt N,M for printing N frames up and M frames down
Allow passing absolute frame ranges to :bt, so you can print e.g. frames 30-25 despite being on frame 15. Not sure what the syntax should be tho... maybe :bt X N and :bt X N,M to print N/M frames around frame X?

Describe alternatives you've considered

Just not showing frames under the current frame: can be confusing and a little annoying in some rare cases, but much easier to implement
Putting some kind of indicator around the current frame in the backtrace: it can be a little hard to find the exact frame when you have >100 frames in the stack

Additional context

One thing that goes somewhat hand-in-hand with this is shortening stack traces, either by not showing the source for everything, or by straight-up not including redundant/irrelevant frames by default (though that's tougher to determine); ideally, this behavior would be togglable with something :bt full or when :te/--show-trace is set. That's a separate issue, but I just want to let you know that I've considered it as well.

I'd love to get feedback on this since it's mostly just a musing and none of these things are set in stone in my head.

(cc @isabelroses since i know you use the REPL and debugger; i'd particularly like to get your opinion on this)
(also cc @pennae since you're the one who thought of this :p)

## Is your feature request related to a problem? Please describe. When debugging in the middle of the call stack, trying to understand the frames around you using `:bt` can be a little frustrating, since you might need to scroll quite a bit to find the slice you're interested in. We could instead only print the stack _around_ the current frame by default, with some syntax to control the range and print other parts of the stack. ## Describe the solution you'd like There's multiple parts to this: 1. By default, when using `:bt`, only print the frames around (e.g. 1 frame up, 1 frame down) the current one (as set by `:st <n>`), maybe with the non-current frames faded (i.e. with `ANSI_FAINT`/`\e[2m`) 2. Allow passing _relative_ frame ranges to `:bt`, such that you can print more or less frames around the current one; this could be something like `:bt N` for printing N frames up (maybe with -N for down? not that useful but eh), and `:bt N,M` for printing N frames up and M frames down 3. Allow passing _absolute_ frame ranges to `:bt`, so you can print e.g. frames 30-25 despite being on frame 15. Not sure what the syntax should be tho... maybe `:bt X N` and `:bt X N,M` to print N/M frames around frame `X`? ## Describe alternatives you've considered - Just not showing frames under the current frame: can be confusing and a little annoying in some rare cases, but much easier to implement - Putting some kind of indicator around the current frame in the backtrace: it can be a little hard to find the exact frame when you have >100 frames in the stack ## Additional context One thing that goes somewhat hand-in-hand with this is shortening stack traces, either by not showing the source for everything, or by straight-up not including redundant/irrelevant frames by default (though that's tougher to determine); ideally, this behavior would be togglable with something `:bt full` or when `:te`/`--show-trace` is set. That's a separate issue, but I just want to let you know that I've considered it as well. I'd love to get feedback on this since it's mostly just a musing and none of these things are set in stone in my head. (cc @isabelroses since i know you use the REPL and debugger; i'd particularly like to get your opinion on this) (also cc @pennae since you're the one who thought of this :p)

❤️ 1

jade added the

Area/repl

Area/repl/debugger

labels

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

jade commented

2026-04-28 15:07:39 +00:00

Owner

I've not thought very hard about this, so definitely let's keep having some more ideas as well, but I think it's worth looking at how gdb and lldb handle bt limits. I would also maybe consider the way list +5 works in gdb where you can repeatedly hit enter to rerun the command which then gives you (iirc?) 5 more lines, relatively.

I've not thought very hard about this, so definitely let's keep having some more ideas as well, but I think it's worth looking at how gdb and lldb handle bt limits. I would also maybe consider the way `list +5` works in gdb where you can repeatedly hit enter to rerun the command which then gives you (iirc?) 5 more lines, relatively.