You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thank you @gotcha for creating such a wonderful debugging tool, ipdb.
I have a few requests that I believe would help ipdb be more useful for interactive debugging. I am not making recommendations to change the default settings, but rather to add fiddly knobs (for e.g. ~/.ipdb) for advanced users.
Note: After digging around in the source for ipdb, I now realize it's a relatively lightweight wrapper around ipython, and most of these features would need to be implemented in ipython's debugger.py. That said, having the fiddly bits configurable are still required for those features to be useful, so I'll describe the features and possible configuration points here.
Feature: Allow subsection [ipdb.context]
Currently, the way to specify the absolute number of lines for ipdb context is:
I suggest that, in addition to #230, a subsection ipdb.context is added, which will allow specifying values other than just lines (as I'll explain below).
# ~/.ipdb[ipdb.context]lines=10
Breaking out a ipdb.context section with a lines property seems like unnecessary fluff, but it allows us to add different fiddly bits for controlling color.
Feature: Allow specifying a NEGATIVE value for lines
Sometimes I want as much context as I can get on a screen, but printing the ENTIRE function would take up more than a screen.
To support this, I propose ipdb.context.lines supports negative values, which are subtracted from the height of the terminal window.
Python has os.get_terminal_size() which can retrieve these values trivially.
One then might be able to write an ~/.ipdb that looks like this:
# ~/.ipdb
[ipdb.context]
lines=-10
Which would print as much function context as possible, but max out at printing term_lines-10 lines.
This should additionally be capped at the size of the function -- e.g. if I have a 5-line function and specify ipdb.context.lines=-10, only those 5 lines should be printed. If the debugger is at a line in the global / module scope (i.e. not in a function / method / class) it would still print term_lines-10 lines in total.
This has the ultimate effect of running ll at the prompt (instead of l), and limiting its output on both ends such that the current line is centered, and has the --> arrow pointing at the current line.
Feature: Dynamically recalculate lines, when negative
Now that we can specify a negative number of lines, the issue arises that the terminal may be resized at any point in time, and the context lines printed should reflect this.
This would mean re-calculating the number of lines to print every time the prompt is shown. This should be straightforward to implement:
It appears one can also specify the $IPDB_CONTEXT_SIZE environment variable, in addition to the configuration file.
This variable should also behave the same as above, when given negative values.
Feature: Add support for ipdb.context.function
ipdb has a small default context size, and this can be changed at runtime or via the configuration file. The l command shows the next few lines, but I'm particularly interested in the ll command which shows the whole function.
While the above features effectively allow us to print the "entire function, up to some limit based on terminal height", setting ipdb.context.function would ALWAYS print the entire function, ignoring ipdb.context.lines.
# ~/.ipdb[ipdb.context]lines=-10
function=True
ipdb.context.lines and the calculations from above would still take effect when the debugger is in the global / module scope.
Feature: Add support for [ipdb.backtrace]
The w / where / bt functionality of ipdb is very useful. It might also be useful to display a shorter version of the stack trace, where just the /path/to/file(line)function_name(args) is displayed.
#~/.ipdb[ipdb.backtrace]show=True
Might cause something like this to be printed before the source context lines:
Which is the same as the current display, but without showing N lines of context in each frame. The bt command itself would not be modified by this.
Interaction with this functionality (i.e. printing the abbreviated call stack) combined with a negative [ipdb.context.lines] would make the code slightly more complex, since we would want to ensure all of the abbreviated backtrace lines appear, and then as much context as possible appears -- but without the total number of printed lines exceeding the terminal height.
It may also be useful to have ipdb.backtrace.frames be an integer indicating the MAXIMUM number of frames to show at the prompt. For example:
#~/.ipdb[ipdb.backtrace]show=True
frames=20
Feature: Control context lines for bt command
Since all of the above features mess with the (currently singular) number of lines of context to display, there may be a need to specify the number of context lines shown for the bt command itself, when manually invoked.
Consider something like:
#~/.ipdb
[ipdb.backtrace]
lines=5
One might set lines=0 to get behavior similar to the above feature [ipdb.backtrace.show], and this common code path could be used to implement both features.
The text was updated successfully, but these errors were encountered:
First, thank you @gotcha for creating such a wonderful debugging tool,
ipdb
.I have a few requests that I believe would help
ipdb
be more useful for interactive debugging. I am not making recommendations to change the default settings, but rather to add fiddly knobs (for e.g.~/.ipdb
) for advanced users.Note: After digging around in the source for
ipdb
, I now realize it's a relatively lightweight wrapper aroundipython
, and most of these features would need to be implemented inipython
'sdebugger.py
. That said, having the fiddly bits configurable are still required for those features to be useful, so I'll describe the features and possible configuration points here.Feature: Allow subsection
[ipdb.context]
Currently, the way to specify the absolute number of lines for
ipdb
context is:With #230, this might look like:
I suggest that, in addition to #230, a subsection
ipdb.context
is added, which will allow specifying values other than justlines
(as I'll explain below).Breaking out a
ipdb.context
section with alines
property seems like unnecessary fluff, but it allows us to add different fiddly bits for controlling color.Feature: Allow specifying a NEGATIVE value for lines
Sometimes I want as much context as I can get on a screen, but printing the ENTIRE function would take up more than a screen.
To support this, I propose
ipdb.context.lines
supports negative values, which are subtracted from the height of the terminal window.Python has
os.get_terminal_size()
which can retrieve these values trivially.One then might be able to write an
~/.ipdb
that looks like this:Which would print as much function context as possible, but max out at printing
term_lines-10
lines.This should additionally be capped at the size of the function -- e.g. if I have a 5-line function and specify
ipdb.context.lines=-10
, only those 5 lines should be printed. If the debugger is at a line in the global / module scope (i.e. not in a function / method / class) it would still printterm_lines-10
lines in total.This has the ultimate effect of running
ll
at the prompt (instead ofl
), and limiting its output on both ends such that the current line is centered, and has the-->
arrow pointing at the current line.Feature: Dynamically recalculate lines, when negative
Now that we can specify a negative number of lines, the issue arises that the terminal may be resized at any point in time, and the context lines printed should reflect this.
This would mean re-calculating the number of lines to print every time the prompt is shown. This should be straightforward to implement:
Feature: Same results for
$IPDB_CONTEXT_SIZE
It appears one can also specify the
$IPDB_CONTEXT_SIZE
environment variable, in addition to the configuration file.This variable should also behave the same as above, when given negative values.
Feature: Add support for
ipdb.context.function
ipdb
has a small default context size, and this can be changed at runtime or via the configuration file. Thel
command shows the next few lines, but I'm particularly interested in thell
command which shows the whole function.While the above features effectively allow us to print the "entire function, up to some limit based on terminal height", setting
ipdb.context.function
would ALWAYS print the entire function, ignoringipdb.context.lines
.ipdb.context.lines
and the calculations from above would still take effect when the debugger is in the global / module scope.Feature: Add support for
[ipdb.backtrace]
The
w
/where
/bt
functionality ofipdb
is very useful. It might also be useful to display a shorter version of the stack trace, where just the/path/to/file(line)function_name(args)
is displayed.Might cause something like this to be printed before the source context lines:
Which is the same as the current display, but without showing N lines of context in each frame. The
bt
command itself would not be modified by this.Interaction with this functionality (i.e. printing the abbreviated call stack) combined with a negative
[ipdb.context.lines]
would make the code slightly more complex, since we would want to ensure all of the abbreviated backtrace lines appear, and then as much context as possible appears -- but without the total number of printed lines exceeding the terminal height.It may also be useful to have
ipdb.backtrace.frames
be an integer indicating the MAXIMUM number of frames to show at the prompt. For example:Feature: Control context lines for
bt
commandSince all of the above features mess with the (currently singular) number of
lines
of context to display, there may be a need to specify the number of context lines shown for thebt
command itself, when manually invoked.Consider something like:
One might set
lines=0
to get behavior similar to the above feature[ipdb.backtrace.show]
, and this common code path could be used to implement both features.The text was updated successfully, but these errors were encountered: