fix: use terminal encoding instead of default charset in VirtualTerminal (fixes #1821)#1822
Conversation
…nal (fixes jline#1821) The MasterOutputStream in VirtualTerminal used Charset.defaultCharset() to decode bytes, which on Windows is typically Windows-1252 instead of UTF-8. This caused multi-byte UTF-8 characters like the ellipsis (U+2026) to be garbled, making StatusTest.testStatusLineTruncation fail on Windows.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
…nal (fixes #1821) (#1822) The MasterOutputStream in VirtualTerminal used Charset.defaultCharset() to decode bytes, which on Windows is typically Windows-1252 instead of UTF-8. This caused multi-byte UTF-8 characters like the ellipsis (U+2026) to be garbled, making StatusTest.testStatusLineTruncation fail on Windows.



The
MasterOutputStreaminVirtualTerminalusedCharset.defaultCharset()to decode terminal output bytes. On Windows, the default charset is typically Windows-1252, not UTF-8. This caused multi-byte UTF-8 characters like the ellipsis (…, U+2026) used byStatusfor line truncation to be decoded incorrectly, producing garbled output and failing thetestStatusLineTruncationassertion.The fix uses
encoding()(inherited fromAbstractTerminal) which returns the charset explicitly passed to the terminal constructor —StandardCharsets.UTF_8in the tests.Summary by CodeRabbit