[BUG] While using cursive, stacktrace (on panic) are never printed to (non-alternate) screen

[hasezoey]

Describe the bug Using cursive and a panic comes up (example via a todo! or explicit panic!) does not show up at all once .run has been called and the panic originates from a view

To Reproduce

• have the cursive repo cloned
• add todo!("test") to example themed_view in function show_dialog (anywhere in the function) (or any other example)
• run example
• observe no stacktrace, but bad return code

Expected behavior Cursive should exit all screen modes, but not prevent stacktraces / have the stacktraces printed after

Screenshots

Environment

• Operating system used Linux (manjaro 23.0.0)
• Backend used: ncurses (also tested crossterm)
• Current locale LANG=en_US.UTF-8
• Cursive version: crates.io 0.20 AND 5885af0005af753fd76f447a40d19d16bd2acad7

Additional context I have been trying to debug this, but i have not found the cause yet, from what i can tell this problem is backend agnostic (it happens in ncurses and crossterm) and modifying Drop in crossterm (while it is used) almost changes nothing, the only thing that changed something was to comment-out LeaveAlternateScreen, which somehow it still exits the alternate screen (maybe because of my shell or terminal on process exit?) where it has printed the stacktrace, but formatted very badly

using crossterm directly (without cursive) does not result in this problem, when reset via a panic hook

[gyscos]

Hi, and thanks for the report!

I think the issue is that the message is printed at the time of the panic, before unwinding (and calling drop). Then, unwinding happens, and the screen is cleared.

I see two possible workarounds:

• Redirect stderr (for example manually to a file with 2> err - fine for development, not ideal user experience
• Override the panic handler, save the message/backtrace, and print it after unwindinging. Haven't fully checked how feasible that is, but it might make things more seamless. One problem is that "after clearing the screen" is currently in the drop implementation of the runner. I guess we could re-raise the panic there?

[necauqua]

I'm doing the third possible workaround, which works nicely with custom panic hooks (like color-backtrace) - resetting the terminal state in the panic handler :) Second reset from the backend drop is harmless as setting the terminal state is (should be) idempotent.

Seems to work great - except for vscode terminal which does something weird:

color_backtrace::install()
// reset the terminal before printing the panic
let hook = std::panic::take_hook(); // someday the update_hook method will become stable
std::panic::set_hook(Box::new(move |info| {
    use cursive::backends::crossterm::crossterm::*;
    _ = execute!(
        std::io::stdout(),
        terminal::LeaveAlternateScreen,
        cursor::Show,
        event::DisableMouseCapture,
    );
    _ = terminal::disable_raw_mode();

    hook(info)
}));

my backend is crossterm, you could copy parts of the drop impl of the backend that you use, for me it's good enough for now well you do use crossterm too :)