Skip to content

[BUG] program crashing on particular strings #821

Open

Description

@AnarchistHoneybun

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};

fn main() {
    // Creates the cursive root - required for every application.
    let mut 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

Environment

  • arch linux

Activity

  1. japhir commented on Jun 6, 2025

    @japhir

    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).

  2. gyscos commented on Nov 27, 2025

    @gyscos
    Owner

    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.

    Image

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions