Skip to content

feat(rich): expose code_width and delegate full width handling to rich #717

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

noirbizarre
Copy link

Summary

This pull request is meant to improve the default developer experience with the RichTracebackFormatter by:

  • exposing the code_width parameter (to avoid line wrap with code formatted with a line_length>88)
    • backward compatible: code_width is only set if present (aka. rich>=13.8.0)
  • delegate the terminal width handling to rich which brings support for:
    • reflow (resize during logging is considered for next lines)
    • the wide-spread COLUMN environment variable (allows setting a width from env)
    • default to 80
  • set the default behavior to full terminal width
  • use the same code-wrap behavior (True) that rich logging handler by default

Pull Request Check List

  • Do not open pull requests from your main branch – use a separate branch!
    • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
    • This is not a pre-requisite for your pull request to be accepted, but you have been warned.
  • Added tests for changed code.
    • The CI fails with less than 100% coverage.
  • New APIs are added to our typing tests in api.py.
  • Updated documentation for changed code.
    • New functions/classes have to be added to docs/api.rst by hand.
    • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
      • The next version is the second number in the current release + 1. The first number represents the current year. So if the current version on PyPI is 23.1.0, the next version is gonna be 23.2.0. If the next version is the first in the new year, it'll be 24.1.0.
  • Documentation in .rst and .md files is written using semantic newlines.
  • Changes (and possible deprecations) are documented in the changelog.
  • Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

@noirbizarre noirbizarre force-pushed the rich/code-width branch 2 times, most recently from e4633eb to 9b37e89 Compare March 31, 2025 22:37
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.

1 participant