crossterm-rs / terminal

Unified API for different terminal manipulation libraries.
59 stars 2 forks source link

Printing continues at wrong position when the terminal instance gets out of scope #11

Open phil0x2e opened 4 years ago

phil0x2e commented 4 years ago

Take this Code (I'm using crossterm-backend):

use terminal::{Action, Clear, error, Retrieved, Value};
use std::io::Write;
pub fn main() -> error::Result<()> {
    {
        let mut terminal = terminal::stdout();
        // perform an single action.
        terminal.act(Action::ClearTerminal(Clear::All))?;
        // batch multiple actions.
        for i in 0..10 {
            terminal.batch(Action::MoveCursorTo(0, i))?;
            terminal.write(format!("{}", i).as_bytes());
        }
        // execute batch.
        terminal.flush_batch();

        println!("\ntest1");
    }
    println!("test2");
    Ok(())
}

The output for me looks something like this:

test2
[user@host]$ 
2
3
4
5
6
7
8
9
test1

Is there a way to prevent this behaviour? If not terminal seems to be not suited for use in a library, because anyone that's using the library would always need to keep an instance of the Terminal struct alive (Or at least a struct from the library using it, that itself keeps an instance of Terminal) to be able to properly print something afterwards.

EDIT: Even when you just create an instance of Terminal and do nothing with it and end its scope, this problem occurs.

TimonPost commented 4 years ago

That is weird, I have no clue why that happens. Over here

https://github.com/crossterm-rs/terminal/blob/master/src/backend/crossterm/implementation.rs#L121

I have the drop function. Here it disables raw modes and goes back to the default screen. Since you haven't enabled raw modes and switched to alternate screen this 'shouldn't' do anything. However, maybe it triggers some terminal behavior. This can be tested by simply debugging and commenting on the functions in the drop method.

phil0x2e commented 4 years ago

The issue seems to be the io::stdout().execute(terminal::LeaveAlternateScreen) function call. When I comment out that line in the drop function I get the expected result:

0
1
2
3
4
5
6
7
8
9
test1
test2
[user@host]$ 
phil0x2e commented 4 years ago

Are you able to reproduce the wrong behaviour? For me it happens in almost any terminal I tried, like urxvt, gnome-terminal or xterm. The only terminals, where it works correctly is the virtual terminal of my os and the integrated terminal I use inside of the atom editor.

TimonPost commented 4 years ago

I can give it a shot in some hours

bhgomes commented 4 years ago

@TimonPost Is there an update on this? I want to be able to write to stdout without the screen clearing whenever the terminal instance goes out of scope. For example, when the program ends I want to be able to see the command history.

bhgomes commented 4 years ago

@phil0x2e @TimonPost I found that if one runs terminal.act(Action::EnterAlternateScreen) right before the terminal goes out of scope the problem goes away, presumably cancelling out the extra terminal.act(Action::LeaveAlternateScreen) in the drop. This is a less-than ideal solution, but it seems to work. I'm not sure what the best API choice is here.

TimonPost commented 4 years ago

Hi there, correct, sorry I totally mist this issue. It's correct that raw modes, alternate screen, and mouse capture is disabled at the drop

https://github.com/crossterm-rs/terminal/blob/master/src/backend/crossterm/implementation.rs#L122

I chose this behavior because when a program stops we need to disable those things such that the terminal is back into its original modes. A solution could be, is by storing the terminal instance in an Box or something like that.

phil0x2e commented 4 years ago

@TimonPost Like @bhgomes mentioned it also happens after the program terminates, so you'll never be able to print something, that still needs to be read after your program ended. That really limits the use of this library to very interactive applications. Also that sadly makes it very cumbersome in a library, especially when it only provides functions to the user.