Opened 13 years ago
Closed 12 years ago
#17221 closed Bug (worksforme)
`manage.py` (do not) sends ANSI escape sequences when terminal (can) can't handle them
| Reported by: | rabio | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
manage.py may sends ANSI escape sequences for output colourization. Unfortunately, guessing if terminal support colours is broken. Guessing if output colourisation is desirable do not take all possible use cases into account.
Rationale:
As it is now, partial checking is made (only platform is checked by django.core.management.color.supports_color()) and manage.py may sends colour codes even when terminal can not handle them properly (as it is a case for most, if not all, dumb terminals).
For guessing to work correctly, checking if terminal can handle colours need to be reimplemented. For this, potentially curses.has_colors() could be used but I'm not sure is it supported on windows, though. In addition, django.utils.termcolors allow to request "blink" option (fortunately not used in default palettes), but not all terminals that support colours know how to blink.
I agree that Django's detection for color support in terminals isn't perfect in theory. However, this isn't a core functionality of the framework at all, and the current implementation appears to work sufficiently well in practice.
Could you describe a reasonable use case where the current code fails? If it works fine in most cases, I won't feel a compelling need to re-implement it.
Given this, and the lack of precise ideas for improvements or a solid patch, I'll close this ticket.
However, if it's really a problem that occurs in common setups, or you have a well-tested patch that improves a realistic use case, I'd be glad to revisit this decision.