Open phil0x2e opened 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.
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]$
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.
I can give it a shot in some hours
@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.
@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.
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.
@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.
Take this Code (I'm using crossterm-backend):
The output for me looks something like this:
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.