debugging functionality added
What does this PR do, and why?
This PR adds comprehensive debugging tools to help both users and developers troubleshoot issues in Zulip Terminal:
-
New
zulip-term-debugcommand-line utility with multiple functions:log: Analyzes debug logs for common error patternsconnect: Tests connectivity to Zulip serversterminal: Checks terminal capabilities for compatibilityrun: Runs Zulip Terminal with debugging enabled
-
Improved makefile targets for debugging:
make debug: Run with debug mode enabledmake debug-profile: Run with profiling enabledmake debug-clean: Clean debug files
-
Enhanced documentation in README with examples for:
- Remote debugging workflows
- Profiling for performance issues
- Common troubleshooting steps
As a frequent user of Zulip Terminal, I've sometimes found it challenging to diagnose issues. These tools standardize debugging approaches and make it easier for both users to report problems and developers to solve them.
I'm planning to apply for GSoC 2025 and would love to contribute more to Zulip Terminal in the future!
External discussion & connections
- [x] Discussed in #zulip-terminal in
debugging improvements
How did you test this?
- [x] Manually - Behavioral changes
- [x] Manually - Visual changes
- [x] Existing automated tests should already cover this (only a refactor of tested code)
Self-review checklist for each commit
- [x] It is a minimal coherent idea
- [x] It has a commit summary following the documented style (title & body)
- [x] It has a commit summary describing the motivation and reasoning for the change
- [x] It individually passes linting and tests
- [x] It contains test additions for any new behavior
- [x] It flows clearly from a previous branch commit, and/or prepares for the next commit
@amanagr @neiljp
@sundanc It seems that this is not passing the tests; some of this is related to a common error, but others are down to you - if you don't understand why, please investigate and then ask in the channel :)
It would also be helpful to split this into separate commits - these are independent changes, it seems?
Thank you for your feedback. I've addressed the linting issues in debug_helper.py by replacing f-strings with parameter-based logging to fix the G004 issues. This approach is recommended for performance since it defers string formatting until needed.
Regarding the failing tests, I understand my commit message format needs to follow the project's convention with area: description pattern. I'll update the commit message to match this format.
I also see that I should have separated these changes into different commits since they're independent. In the future, I'll split changes to address different concerns into separate commits for better clarity and easier review.
Let me know if there's anything else I need to address.
@neiljp Finally, it passed all the checks. I cleaned up broken & unformatted codes that are in my forked repo commit history.
Failed a check after sync of latest 2 commits into the fork. Gonna check that out