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

Display path of current source file in header bar #464

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

qhuy4119
Copy link
Contributor

@qhuy4119 qhuy4119 commented Jul 13, 2021

Currently, the full path of the current source file will be displayed.
This usually results in long path. When the path can't be displayed fully in 1 row for whatever reason (the window is resized, not enough space from the beginning,...), after a Ctrl-L (hotkey for redraw screen), it will wrap automatically, creating more rows as needed.
Screenshot_20210713_195215

We have multiple options to resolve this:

  • Leave as is
  • Only display the filename
  • Calculate the length of the string somehow (from shutil.get_terminal_size(), for example)
  • Let user decide in config file
  • Other....

Let's discuss this

fixes #170

Currently, the full path of the current source file will be displayed.
This usually results in long path -> Need more discussions.
The path to current source file will now be calculated dynamically. If
there is enough space, the full absolute path will be shown. Otherwise,
the longest possible path will be shown by trimming the full absolute
path from the left.

If there is an update to the terminal width, the path will be
recalculated when the user runs the next line of code, however the method (next, step, continue).
NOTICE: Pressing Ctrl-l will redraw the screen with the current path, it doesn't recalculated the path string.
@qhuy4119
Copy link
Contributor Author

qhuy4119 commented Jul 15, 2021

I updated it to calculate the path string automatically to fit on 1 line

Currently, path will be updated if the user executes the next line of code by pressing n, s, c in the Source window(every time DebuggerUI.interaction gets called). Ctrl-l to redraw will only redraw the current path. I don't know if it's possible for Ctrl-l to update the path as well.

pudb/debugger.py Outdated
filename = filename[first_dirname_index + 1:]
return filename

caption = [(None, separator.join([info_string, get_source_filename()]))]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on that! This isn't quite the right way to do this IMO. Instead, this should be done in the repaint method for a widget, where Urwid supplies the amount of space available.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need more guidance because I'm not sure what you are referring to.

this should be done in the repaint method for a widget

Are you talking about urwid.Text.render, or some repaint code in PuDB, or something else?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm talking about subclassing urwid.Widget or Text and implementing our own render method.

`Caption` will handle the display of header's content, including the
current source filename
@qhuy4119 qhuy4119 force-pushed the display-source-file-name branch 2 times, most recently from 025e76b to d7fd7ca Compare July 23, 2021 13:09
- Caption is now composed of a CaptionParts namedtuple and a separator, both will be
  passed to Caption explicitly

- separator and parts in CaptionParts will be tuples of the form
  (attribute, text), similar to text markup in urwid

- Caption no longer overestimates the amount of text to be removed.
urwid will raise error if the content in the markup is not of type str,
even when they are convertable. So we have to do the converting.
Use CaptionParts._make() when constructing CaptionParts objects to
increase readability.
@mvanderkamp
Copy link
Contributor

A thought on this: an optional footer might be a better place. The header currently displays very useful information that helps new users get started with using the debugger, and I don't think we should lose that.

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

Successfully merging this pull request may close these issues.

Display the source file name
3 participants