Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Multiple quality-of-life enhancements for ipdb context sizes via configuration file #231

Open
zachriggle opened this issue Jul 21, 2021 · 0 comments

Comments

@zachriggle
Copy link

zachriggle commented Jul 21, 2021

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:

# ~/.ipdb
lines=10

With #230, this might look like:

# ~/.ipdb
[ipdb]
lines=10

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.

>>> term = os.get_terminal_size()
>>> term_columns = term.columns
>>> term_lines = term.lines
>>> print(lines, columns)
85 186

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:

if lines < 0:
  term = os.get_terminal_size()
  lines = term.lines + lines

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. 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:

  /Users/zachriggle/github.com/ipdb/test.py(28)<module>()
  /Users/zachriggle/github.com/ipdb/test.py(25)a()
  /Users/zachriggle/github.com/ipdb/test.py(23)b()
> /Users/zachriggle/github.com/ipdb/test.py(21)c()

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant