[BUG] rich.progress should fallback to use ─ instead of -
See original GitHub issueSo I use wsltty mainly where rich.progress uses the ━━
character for the progress bar. I checked it in cmd.exe and it showed --
for the progress bar. The fallback should be ──
(also used in tables), it would give a connected line.
btw: is there any terminal that does not support the ━
character?
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Source code for rich.console - Rich's documentation!
This method can return a new list of renderables, or modify and return the same list. Args: renderables (List[ConsoleRenderable]): A number of renderable ......
Read more >Ubuntu Manpage: checkbox_ng - CheckboxNG Documentation
xml, is a name of the fallback file that is only created when sending the data to the certification website fails to work...
Read more >Feedback from Content Editor MVC in Wiki (#332629) · Issues
Without a plain text view, frankly I'd rather use the old editor. ... Here, I would appreciate a rich editing experience.
Read more >EPUB 3.3 - W3C
It is inappropriate to cite this document as other than work in progress. ... MUST NOT use the encryption features defined by the...
Read more >T229242 Explore ways to restrict suggestions to a given knowledge ...
Query Wikidata for related articles. A Wikidata query (example) will find articles related to the selected topic area through the P31 property that...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This is still an issue as of now. The fallback character can simply be a
─
. It’s even available in CP437 IBM so every terminal supports it in theory.So the change I mentioned above works, but it has one unexpected side effect. basically options.is_terminal is for checking if the output is a terminal, not specifically command prompt, and because of that the normal behavior also changes. now one thing I notice is that it defaults to ASCII Mode on Command prompt.
So I went on to test if ASCII mode is necessary. and it looks like it isn’t since the normal character also works for me, so I checked a bunch of encodings and most of them seem to work fine. now I am a bit stuck on what to do next
On Powershell with Windows Terminal
Before:
After:

If you want the default character to change to the thinner one then you can add
─