You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
i found this out while using ncspot, here's the original issue raised there. Basically, for particular strings (containing hindi letters, for example) the program just crashes, with the panic message mentioning cursive_core
To Reproduce
this program reproduces the error:
use cursive::views::{Dialog,TextView};fnmain(){// Creates the cursive root - required for every application.letmut siv = cursive::default();// Creates a dialog with a single "Quit" button
siv.add_layer(Dialog::around(TextView::new("मराठी प्रार्थना - Shubham Karoti Kalyanam ")).title("Cursive").button("Quit", |s| s.quit()),);// Starts the event loop.
siv.run();}
Expected behavior
not to crash for any particular string
Thanks!
It seems the problematic graphemes are प्रा and 🚶🏼♂.
Both of these report a width of 3, which is indeed past cursive's max supported width of 2.
On my terminal, both of these have display issues, even outside of a cursive app.
Here is a test just cat'ing a text file, tested on Alacritty, Gnome Terminal, Console (another gnome app), and Wezterm.
The hindi text looks properly handled by all except wezterm. The 🚶🏼♂ emoji was not rendered properly anywhere, with various rendered widths.
I agree that not crashing is already a vast improvement, but I'm not sure how to even test proper rendering when all my terminals are failing somehow.
A disagreement between the width known by cursive (as returned by UnicodeWidth) and the rendered width (the actual number of columns used by the grapheme by the terminal) can lead to UI glitches, like a cell not being redrawn (because we assume it will be covered by the grapheme, but the terminal doesn't actually write in the cell).
I merged the linked PR and added a bit of code to protect against some of these glitches, but it's still not perfect. Well, at least no crash.
Activity
japhir commentedon Jun 6, 2025
May also crash with the string "🌳____🚶🏼♂____🌳"
(haven't tested but get the same bug in ncspot when listing a playlist with this in the name).
gyscos commentedon Nov 27, 2025
Thanks!
It seems the problematic graphemes are
प्राand🚶🏼♂.Both of these report a width of 3, which is indeed past cursive's max supported width of 2.
On my terminal, both of these have display issues, even outside of a cursive app.
Here is a test just
cat'ing a text file, tested on Alacritty, Gnome Terminal, Console (another gnome app), and Wezterm.The hindi text looks properly handled by all except wezterm. The
🚶🏼♂emoji was not rendered properly anywhere, with various rendered widths.I agree that not crashing is already a vast improvement, but I'm not sure how to even test proper rendering when all my terminals are failing somehow.
A disagreement between the width known by cursive (as returned by UnicodeWidth) and the rendered width (the actual number of columns used by the grapheme by the terminal) can lead to UI glitches, like a cell not being redrawn (because we assume it will be covered by the grapheme, but the terminal doesn't actually write in the cell).
I merged the linked PR and added a bit of code to protect against some of these glitches, but it's still not perfect. Well, at least no crash.