Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
phil0x2e opened this issue Feb 25, 2020 · 8 comments

Comments

@phil0x2e
Copy link

phil0x2e commented Feb 25, 2020

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

phil0x2e commented Feb 26, 2020

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
Copy link
Member

I can give it a shot in some hours

@bhgomes
Copy link

bhgomes commented Sep 6, 2020

@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
Copy link

bhgomes commented Sep 15, 2020

@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
Copy link
Member

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants