Closed timon-schelling closed 1 month ago
This is probably the same issue as https://github.com/raphamorim/rio/issues/534. It should be fixed in 0.1.2
.
Not the same bug as in #534 and still present in v0.1.2
.
Tested with the flake in this repo:
nix run github:raphamorim/rio#rio -- -e nix run nixpkgs#btop
Version is 0.1.2:
❯ nix run github:raphamorim/rio#rio -- -V
rioterm 0.1.2
I think pushed a proper fix for it, could you test latest main?
This issue seems to be fixed but some parts of my font are now broken with d86ec56ab17629d4add2f75c50d8e676f7e9d0c4.
In this video on the left d86ec56ab17629d4add2f75c50d8e676f7e9d0c4 on the right v0.0.39:
https://github.com/user-attachments/assets/9b76e413-3db3-4302-b528-e25edfd7b62c
Environment of both processes is identical. Did font loading change in some way?
@raphamorim I should properly create a new issue for this?
yes please create another issue @timon-schelling also, are you using a font different than the default (you can write it down in the new issue)
thank you!
Description
Starting from version v0.1.1
rio
encounters an issue with rendering Text User Interfaces (TUIs) that utilize cursor movement control sequences to redraw parts of the terminal.Steps to Reproduce
btop
btop
inrio
and observe the rendering issues in the terminal.Demonstration
https://github.com/user-attachments/assets/7c0a1009-105e-44fc-b51a-f8fbebebe6f2
btop
stdout that can reproduce the bug.Expected Behavior
The terminal should correctly render TUIs without graphical glitches when using cursor movement control sequences.
Additional Information
I plan to investigate this further when I have the time. Any insights or assistance from the community would be greatly appreciated.
Thank you for your attention. Thanks for creating rio :)